Best practices in product management

• products
• management
• agile
• lean
• design thinking

Being a product leader for me means acting as a hub between business, UX and engineering, while setting a strong and clear product vision. The UX part is especially close to my heart as working together with designers brings back some creativity that’s sometimes lost in the tech field. The three sets (business, UX and engineering) are equally important, although depending on the product, organization and role one or two can have more weight over the other(s).

An excellent leader is able to juggle between different responsibilities and removes roadblocks inside teams or between teams. He/she can comfortably wear different hats and practically acts as an ‘intrapreneur’, a.k.a. an entrepreneur inside an established company. A good product and innovation leader is user driven, talks to customers and is laser focused on driving the product and thus the whole organization in the right direction by balancing quantitative and qualitative inputs and outputs. Iterating through this process with an effective roadmap that is able to correctly prioritize is at the heart of product management.

A set of diverse experiences has allowed me to manage teams, web products and business relationships effectively during my over 10 years long career, with the main driver being: the best ideas win, no matter the organizational structure and where they come from. I have found that having a transparent organization where everyone feels empowered with a strong culture for open communication, leveraging frameworks like Objective and Key Results instead of anachronistic structures that are too hierarchical, is a net benefit for the system.

Agile, Lean and Design Thinking

Remember the three sets? These categories and skillsets are crucial. They make the product manager role interdisciplinary, challenging and interesting. That's also why this kind of role is very similar to the technology entrepreneur. Product Managers who founded startups have an advantage over others who didn't and startup founders have an advantage if they are product focused.

Many of the best principles for product management come from well-tested practices from each of the three areas: Agile from the engineering side, Lean from the business side and Design thinking from the design side. This division is an oversimplification as agile, lean and design thinking principles overlap quite a bit between the three categories.

The Agile manifesto for instance is from 2001 and synthesized a couple of decades of best practices in software engineering and engineering management. Lean and Design Thinking came a bit later, popularized by the startup environment and the technology sector of the San Francisco bay area. We won't go over Lean and Design Thinking in this post but you'll see there's quite a few ideas there that are borrowed from the Agile movement. So it's a good idea to cover all three, try the frameworks in your work, mix and match, experiment and adopt what works best for you and your organization/team in order to get to a great product culture.

The Product Manager/Product Owner

While you can be a great product manager in an innovative company without using Agile, a lot of the product management best practices come from there so I'll quickly cover the basics. In Agile, a product manager is basically called the Product Owner (PO). The PO main goal is to push forward a product vision with a focus on the 'WHY'. Especially when the product is new, the PO doesn't know the details of what the product is going to do but he or she is clear on why we are building it. What problems is it going to solve and for who.

The stakeholders

The stakeholders are the people who are going to use the product or be affected by it. Our goal is that the stakeholders will just love our product. The PO ideas and stakeholders needs are outlined into user stories. They get piled up in a set called the product backlog. An important part of a PO's job is to correctly outline user stories and prioritize them (a process that will eventually coalesce into a roadmap).

The development team

The third important group is the development team. Ideally small, cross-functional and self-organizing. They release early and often, usually 4-6 stories per week (or story points). Some stories are big so they can count as two, some are small and count as half; what they can deliver per week is their capacity/velocity.

In order to maintain a steady pace and not get slowed down by technical debt or manual regression testing, the development team invests heavily in automated testing, continuous integration and continuous deployment (a CI/CD pipeline). Therefore, every story has at least one automated acceptance test at the feature level and most of the code has automated unit tests.

Prioritization

The stakeholders will likely ask for many things, usually way more that the weekly capacity of the dev team. And they usually don't even know what exactly they want/need! If we try to please the stakeholders every time, we'll overload and demotivate our team. The Scrum and Extreme Programming (XP) way of avoiding this problem is called "Yesterday's Weather". For example, if we finished 5 features last week, which 5 features should be build this week? The Product Owner job is to figure out, and clearly communicate why, the dev team should build precisely these 5 features next, out of all the pending user stories in the product backlog.

The Kanban methodology approaches this by limiting Work in Progress. In our previous example the team WIP limit is 5 as they decided it's the optimum number of stories to work on at the same time to be both fast and effective. With this approach, the team aims to never overperform (work on more than 5 stories per week) or underperform (work on less than 5 stories per week). Without a product owner though, the queue or product backlog would quickly pile up and get messy. So the PO will have to practice saying no to the stakeholders. Saying yes can be easy but especially in this context, less is more. It's hard but it doesn't have to be a lonely job. The PO works collaborates with both the dev team and the stakeholders to figure out how to correctly prioritize user stories.

In order to prioritize correctly, there has to be a good estimation of the value and size (implementation difficulty) of each user story. Some stories are business critical, some are just cake toppings. Some can take a few hours to build, some others could take months. There's usually no correlation between business value and implementation difficulty. So here it can be helpful to build a prioritization matrix, where the user stories/features are the rows and the prioritization criteria are the columns. On the columns you can have implementation difficulty, business value and other metrics specific to your industry. If two features have the same difficulty but one has higher business value, then prioritize the one with higher value. Again, a lot of these are guesstimates and to get more precise, research, team collaboration and good communication are all needed. At the beginning the estimations will not be so good but over time they will improve and so will the learnings for the team overall. Every time we we deliver to real users, we collect data and metrics to help with our future decisions. This tells you that aiming for perfection at the beginning is not so smart as that's when we know the least.

In order to deliver early and often, you need to break stories down into smaller pieces (usually a few days of work per story). This breakdown can be done in a just-in-time fashion as we learn along the way, taking advantage of the latest information so that the more defined, smaller stories can get pushed in front of the product backlog. This is called "backlog grooming" and it can be a team workshop to run once per week.

Communication and ownership

As the Agile manifesto says, "individuals and interactions over processes and tools". Communication is a crucial skillset for the successful product manager. The goal is not to babysit the dev team by micromanaging user stories but to make sure everybody understands the vision. This is what Steve Jobs was great at and ultimately what great CEOs excel at. This is why Google and other companies refer to product managers as the "CEOs of their products". Another reason is ownership. The ability to take ownership and responsibility (avoid blaming) is fundamental to the successful (product) manager. Besides the vision, it is important to let the dev team get in direct contact with the stakeholders and that there is a short feedback loop in terms of frequent deliveries to real users. Igniting this virtuous cycle will make any micromanaging attempt unnecessary and will allow the product manager to stay focused on the big picture. In bigger organizations, it's also really important to sync up with other product managers (especially to deal with dependencies) as well as with senior management.

Trade-offs

There's obviously quite some trade-offs to make in this role, for example between different types of value and types of risk.

1. business risk: are we building the right thing?

2. team risk: can these people execute?

3. tech risk: will it work and scale?

4. cost risk: will the budget cover the whole thing?

5. schedule risk: will we finish on time?

Knowledge is the opposite of risk here so, again, especially at the beginning we focus on knowledge acquisition rather than trying to get a bullseye on risk estimation and get stuck in analysis-paralysis mode. So we focus on early experiments and interface prototypes, talking with customers and understanding their top pain points and needs. This is basically the Lean approach. This means that at the beginning the (inexperienced) stakeholders (including investors) might feel that there is not much progress being made. We are still doing something very valuable though as we are reducing risk. At a later stage, once we know exactly what we are building and how, we'll focus on execution, building the highest value stories first so progress will be more and more apparent until it will eventually plateau. At this point the team might decide that it's time to move to another more important project or a new feature area within the same product. In other words implement business agility.

The value being generated is then not just external (customer value) but internal as well (team/company knowledge). We need to find a balance in this trade-off. Same goes for short term vs long term thinking. A typical example is should we focus on a bug-fix or a new feature or a tech upgrade?

Here comes the famous development trilemma:

1. building the right thing

2. building the thing right

3. building it fast

In a perfect world it would be all three but it is almost never the case. If we only focus on 1 and 2 we might miss the market window and in business timing is everything. If we instead focus on 1 and 3 we will eventually run into painful technical debt. Doing 2 and 3 is potentially even worse as we'll build something nobody wants. No organization, from startups to huge conglomerates, is free of this major tradeoff. To try to deal with this, organizations came up with different roles and structures. The engineering manager is likely to focus on 2, the product manager on 1 and the project manager or agile coach on 3. Obviously the roles can differ greatly depending on the industry and organization. The goal here should be to get a good culture going, diverse points of views and healthy collaborations instead of politics.

Another tradeoff, mostly for mature products or when they reach End Of Life, is between working on new features and maintenance. In bigger companies this issue is about how to deal with handoffs. When a team has built a product and acquired all the surrounding knowledge, it can be painful to have another team take over if the original team has to move on to other areas. So what can happen here is that the team continues to maintain the 'old' product while working on a new one. This impacts velocity. This can be somewhat solved by implementing another set of best practices and bake them in the engineering culture of the organization. As an example Amazon has a long-standing culture of having a Service-Oriented Architecture for every product. This means that teams can have actual agility.

Managing expectations

An import aspect of the product manager role is about managing expectations. This can have several facets but let's take timelines into consideration here. Often stakeholders will ask when will a specific feature or set of features be completed. The key here is to not lie! Be realistic about what can the team deliver by that date or estimate when can this feature be delivered. Once the team has worked together for a while and the velocity is somewhat stable, you can draw two lines into the future to communicate those estimates: one for the worst case scenario and one for the best case scenario. There's an uncertainty gap between the two lines. There can be situations where you have to negotiate with stakeholders about delivery timelines. Be honest and say that with the data that you have, you estimate that by this date you'll have these features in the worst case scenario. It's about personal style as well but it's usually better to underpromise and overdeliver than overpromise and underdeliver. You can always develop more features later.