How do you best lead the stakeholders and development team as the person in charge of the product? One way to answer this question is to avoid unhelpful but common leadership styles. Two of these styles, feature broker and product dictator, are shown in the picture below.

A feature broker is a product person who relies on others—the stakeholders, development team, management, users, or a customer—to come up with ideas and make product decisions. As its name suggests, this leadership style mediates between different parties and tries to broker a deal.

A product dictator—also called a coercive leader—exhibits the opposite leadership style: the individual assumes that she or he knows best what needs to be done. Consequently, the person makes the product decisions and expects others to support them.

While being a feature broker shows that the individual is able to connect with other people and appreciate their ideas, it carries the risk of trying to please everyone thereby creating a product that doesn’t do a good job for anybody. In the worst case, you end up with a feature soup, a loose collection of features requested by the users, customers, or stakeholders. Such a product typically has a weak value proposition, offers a poor user experience, and is therefore unlikely to become a success.

Being a product dictator is equally undesirable, unless your product is in a crisis. Being decisive and having a clear vision of where you want to take the product is certainly helpful. But if you believe that you are always right, and you know best, then you probably end up making wrong decisions: It’s very unlikely that one person has all the knowledge and skills required and can counteract all cognitive biases.

Even if this was the case, this leadership approach creates an unhealthy work environment: The development team members and stakeholders are told what to do and are expected to fall in line to support the decisions—no matter if they agree or not. This dampens their motivation, wastes their creativity and knowledge, and leads to weak buy-in. What’s more, people are likely to blame you if the product does not deliver the desired benefits. To make things worse, you may end up worn-out and overworked, as you want to be involved in all decisions.

Recognise Your Leadership Bias

Feature broker and product dictator are extreme leadership styles, of course. But it seems that most of us, including myself, gravitate towards one of the two extremes and are inclined to act as a feature broker or product dictator. If that’s the case for you, then don’t feel bad. Recognising your leadership bias is a key step towards becoming a better, more effective product leader, as I explain below.

If you are new in a product role or if you have just taken on a new product, and your knowledge about the users, needs, business goals, and competition is still weak, then you often end up asking the stakeholders and dev team for suggestions and are more likely to accept their requests. Similarly, if you work in an organisation where product management is not recognised as a function in its own right, or if you look after a bespoke product for a customer, you may get pulled towards the feature broker style. Additionally, if you find it generally difficult to say no to others and want to please people, or if you suffer from imposter syndrome and believe that others know much more about the product than you, then this trait will draw you towards the feature broker style.

If, however, the dev team and stakeholders are less experienced than you, or if you hold a senior position in the company, then people may well expect you to decide and tell them what to do. Even when you involve them in the decision-making process, people may require encouragement to speak their mind and think out of the box. Moreover, if you find it hard to trust others, if you are critical of yourself and other people, if you are a bit of a perfectionist or control freak, then you are likely to lean towards the product dictator pattern.

Be a Balanced Product Leader

Once you understand your leadership bias, you can take the next step and address its causes. This will help you become a more balanced and effective leader grounded in the middle of the leadership continuum shown in the picture below.

If you gravitate towards the feature broker style, then empower yourself. Acquire the relevant knowledge and learn as much as you can about the market; and consider improving your people skills and virtuous qualities. This will earn you trust and respect, and help you lead the decision-making process. Additionally, you might have to overcome people-pleasing or imposter habits. You may also have to practice saying no—even if it is difficult initially—and accept that difficult conversations belong to your work. At the same time, take advantage of your strengths, such as connecting with people and appreciating their ideas.

Additionally, organisational impediments might have to be overcome to help you be a more effective product person. If you lack management support or if there is no established product management function in the organisation, then you may want to work with your ScrumMaster or coach on addressing the issue and lobby for more authority. Similarly, if you create bespoke products, a customer makes the key product decisions, and you end up being a proxy between the individual and the dev team, then you may require senior management support to change the situation. In some cases, you may have to accept the setup for now, and try to change your level of authority on the next project.

However, if you are biased towards the product dictator style—if you are good at making decisions, but not so good at appreciating other people’s ideas—then empower the development team and stakeholders. Coach the individuals and help them acquire the relevant knowledge. Actively involve people in the decision-making process, and show them that you value their input. Invite the stakeholders and development team representatives to collaborative product strategy and roadmap workshops; involve the dev team in the product backlog work; and write user stories together, for instance. This might increase your workload in the short term, but it generates support and buy-in, and it allows you to delegate work in the future, for example, some of the story refinement work to the development team.

If you have some perfectionist or controlling tendencies, then bring to mind that none of us is perfect, cultivate compassion for yourself and others, be grateful for the work other people do, and decide to trust the development team and stakeholders, once you have agreed on shared goals. At the same token, don’t forget your strengths including being decisive and not shying away from difficult conversations.

Great leaders are made, not born. Therefore, develop yourself, leverage your strengths, and work on your weaknesses. Don’t forget that change seldom happens overnight. It takes effort, discipline, and self-compassion: Learning new skills can involve setbacks, and some habits die hard, as I know from my own experience.

As the person in charge of a product, you are responsible for achieving product success. But you can’t accomplish it on your own and rely on the development team and stakeholders. Their contributions are vital to design, implement, provide, and support a successful product. At the same time, you can’t tell the individuals what to do or assign tasks to them, and you are typically not in a position to offer incentives, like a bonus or pay rise.

So how can you align people and ensure that everyone moves in the same direction and carries out the necessary work? And how do you ensure sufficient autonomy so that the individuals can own their work? Part of the solution is to establish a set of shared goals—goals that people support and that help you progress your product. The development team and stakeholders then use these goals to determine the work they have to do—be it creating a marketing strategy, investigating a new technology, or preparing the distribution channels. This focuses everyone on the joint outcomes you need to achieve, and it gives people the freedom to manage their work, thereby creating purpose and autonomy.

A Chain of Goals

Let’s take a look at the type of goals that help you move your product forward and align people.

The picture above shows a set of goals that are linked and operate at different levels. The first and possibly most powerful goal is the vision, which describes the ultimate reason for creating your product and the positive change it should bring about. An example I like to use is healthy eating. As this example shows, the vision is an inspirational, visionary goal that cannot be measured.

The user and business goals are strategic goals that are derived from the vision. The former describes the problem that users want to see addressed, for example, lose weight, or the benefit that users want to obtain, for instance, reduce the risk of developing diabetes. A business goal states the benefits the company developing and providing the product wants to achieve, for instance, diversify the business, open up a new revenue stream, and develop the main brand. Whatever user and business goals you choose, make sure that they are specific and measurable. This allows you too select the right key performance indictors (KPIs) and understand if your product is meeting its goals. I like to capture vision, user, and business goals on my Product Vision Board.

With user and business goals in place, you can take the next step and determine release goals. Each release goal should be a step towards meeting the user and business goals, and it should describe the specific benefits a major release or product version will provide, for example, acquire users, increase engagement, generate revenue, or remove technical debt to future-proof the product. I like to capture release goals on the product roadmap together with their metrics, and I have a preference to work with a goal-oriented (or themed) roadmap like my GO Product Roadmap.

Finally, identify the right sprint goal. A sprint goal states the desired outcome of a sprint, such as find out if users are willing to share personal information, test integration with leading smart scales, or finish the dashboard to release a first version to the test users. I recommend that you derive the sprint goal from the goal of the next major release and state it on the sprint backlog or task board. This ensures that each sprint moves you closer towards the release. (If your development team works with Kanban instead of Scrum, then it might still be helpful to agree on weekly goals that direct the work of the team members.)

Every sprint goal should be a step towards a release goal; every release goal should help you reach a user or business goal; and the user and business goals should help you realise your vision. The different goals are therefore linked and form a chain that covers all product planning aspects: visionary, strategic and tactical ones.

Getting to Shared Goals

It’s great to know what goals are helpful to direct and align the development team and stakeholders. But it’s not enough. The individuals involved in developing and providing the product must support the goals to move together in the same direction. Otherwise, people are likely to follow their own goals; orchestrating everyone’s efforts will become very difficult, if not impossible.

The best way to achieve strong-buy in is to actively involve the right people in the goal-setting process. I like to bring together the development team and key stakeholders and run a series of collaborative workshops: a strategizing workshop to come up with a meaningful, inspiring vision everybody believes in and a product strategy that contains user and business goals; a roadmapping workshop that identifies realistic release goals using the product strategy as an input; joint product strategy and roadmap review meetings to update or change to the strategy and roadmap; and sprint planning meetings that establish meaningful and realistic sprint goals. (Note that stakeholders don’t participate in sprint planning meetings. Instead, they are invited to sprint review meetings, which provide an opportunity to offer feedback on the latest product increment.)

Bringing together the right people allows you not only to generate strong buy-in; it also leverages their collective knowledge and creativity, and it establish meaningful goals—goals that are worthwhile to pursue. But a collaborative approach also carries the risk of friction and conflict. In the worst case, powerful individuals (HIPPOs) might highjack the goal-setting process and dictate goals.

To mitigate these risks, I recommend that you involve an experienced ScrumMaster, coach, or facilitator, who sets the ground rules, facilitates the workshops, ensures that everybody is heard, and nobody dominates. Additionally, make sure that you apply the right decision rule. As vision, user, and business goals are particularly crucial, you should attempt to achieve consensus with everybody fully supporting the goals. If that’s not possible, then discuss different options with the dev team and stakeholders, and then you decide as the person in charge of the product. (You may want to download my decision-making chart to select the right decision rule.)

If you feel that an open, collaborative approach is not feasible, then consider running individual meetings with the various stakeholders and development team to discuss a draft goal, incorporate people’s feedback, and rework the goal so that everybody can support it.

No matter which approach you choose, be careful that you don’t become a goal broker or mediator: Actively shape the goals and avoid making weak compromises to strike a deal or please people. Don’t be afraid to push back and say no when appropriate. At the same time, appreciate people’s ideas and concerns even if you feel they are not helpful or appropriate. When you care about the individuals, empathise with them, and understand their perspective and needs, they are more likely to support a goal even if they don’t fully agree with it.

Product discovery is a team sport. You should therefore involve the right people in the discovery work and secure enough of their time. I find it helpful to form a product discovery team that consists of:

Involving others in the discovery work allows you to leverage their knowledge and expertise, builds rapport, and creates support for key product decisions including the selection of a specific market segment and stand-out features.

A UX designer, for example, might help you observe and interview users; and a developer and tester might advise you on technical feasibility, identify technical risks, and build prototypes; a sales rep might get you in touch with target users and help you with competitor research; a ScrumMaster might facilitate collaboration and advise on process issues—for instance, which process and tools should be best used to visualize and track the discovery work. (I prefer to use a Kanban-based process and a Kanban board, as I discuss in my book Strategize in more detail.)

Focus on Problem Validation, not Solution Building

Your product discovery work should focus on nailing the value proposition, target group, business goals, business model, and stand-out features of the product—not on writing user stories, designing the user interface, or building the actual solution. Your goal should be to mitigate the risk of building a product nobody wants and needs, not to figure out the product details.

Having said that, it’s ok to address key UX and technology risks and evaluate important user interaction and architecture options as part of the discovery work. But the bulk of the UX design, user story writing, and technology work should be done after you have successfully validated the problem.

To get your focus right, consider using a tool like my Product Vision Board to capture your idea, and identify assumptions and risks.

Do Just-Enough Product Discovery Work

Minimise the amount of time you spend on product discovery in order to accelerate time-to-market. Explore the key assumptions and risks in your product strategy and business model by systematically testing and addressing them in an iterative fashion using, for example, observations, interviews, surveys, and prototypes. You should aim to get a good enough product out as fast as possible, and then adapt it to the market feedback. There is no way to guarantee that the product strategy and business model are spot on, and that the new product or next version will be a success.

But don’t rush the necessary work, and resist the temptation to jump start building the actual product. If you can’t confidently state why people are going to use your product, who those individuals are, what makes your product stand out from the crowd, and why it’s worthwhile for your business to develop and provide the product, then you are not in a position to develop the actual solution. Instead, continue the discovery work (persevere or pivot), or be willing to recognise that your idea is not going to work. If that’s the case, kill it, and move on to another product idea.

Talk to the Users

With all the product discovery work that needs to happen, it can be easy to lose sight of the most important success factor—the people who are going to use the product. There is no point in coming up with a smart business model and sophisticated user interactions, if you don’t know who the users are, what they may be struggling with, and what works well for them, and what doesn’t. If the users don’t need and like your product, you will find it hard to monetise it and achieve product success.

Therefore, get out of the building (as Steve Blank says) and meet target users face-to-face as part of the discovery work. I know that’s not always easy to do. But to succeed with product discovery, I find it paramount that you—the person in charge of the product—carry out user research yourself and develop a deep understanding of the user needs.

When talking to users, take a genuine interest in the people you meet. Have an open mind and let go of preconceived notions about the problem you think the users have or the solution you believe they need. This allows you to discover what people really want and need thereby maximising the chances of creating a successful product.

Don’t Handoff Product Discovery Work

The people involved in product discovery should also participate in building the actual solution. The UX designer, developer, tester should work on the development team. The stakeholders should regularly attend product strategy and roadmap reviews, as well as sprint review meetings. This speeds up the product innovation process, creates a smooth transition from discovery to delivery activities, and mitigates the risk of loss of knowledge.

Handing off the discovery work is ineffective and wasteful: It requires detailing the knowledge acquired in form reports and other artefacts. This is time-consuming, and it is likely to lead to misunderstandings and loss of knowledge—it is hard to precisely capture the discovery learnings, and written information is open to misinterpretation.

Therefore, refrain from using separate discovery and delivery teams. I find it is usually better to involve more people from the development team rather than opting for two distinct teams. Remember that quickly learning what to do (and what not) and quickly delivering the right solution are more important to product success than cost efficiency and saving money—at least at the early life cycle stages.

Consider Timeboxing the Product Discovery Activities

Knowing upfront how much time and effort will be required to carry out the necessary discovery work is tricky. New risks and work items often emerge as part of the validation work. Luckily, there is a straightforward solution: timebox your product discovery work. This technique is particularly useful when you work on a new product or when you make a bigger change to an existing one, for example, to take the product to a new market in order to extend its life cycle.

A time box is a fixed period of time, such as one week, that cannot be extended. At the end of the time box, the work stops, and you reflect on what has been achieved. If the work has not been completed, and your product strategy and business model still contain significant risks, you have two options: add another time box—and possibly pivot—or stop the work.

Consider holding weekly review meetings that involve the people carrying out the validation work as well as the management sponsor. Use the meetings to reflect on the risks that are being addressed and the learnings that you have achieved; consider the risks that still exist in your product strategy and business model; and decide if and how to continue.

Don’t Limit Product Discovery to New Products

While the traditional usage of the term suggests that product discovery is the first stage in a new-product development process (see Cooper’s Stage-Gate™ process), it would be a mistake to limit product discovery to new products.

As your product grows and matures, its value proposition, market, stand-out features, and business model will change. To make and keep your product successful, it is paramount that you proactively review and adjust your product strategy, roadmap, and business model. These adjustments sometimes require little or no product discovery work.

But when you find that bigger changes are required, such as, taking your product to a new market or adding features and redesigning the user experience to sustain growth, you are likely to find that you have to carry out specific discovery work, as the picture below shows. If that’s the case, then I recommend showing the work on your product roadmap.

The picture above shows that there is a correlation between the product’s life cycle stage and the amount of product discovery required. As the product ages, the discovery effort tends to go down. But whenever you make a bigger change like a life cycle extension, the effort increases again. Modern product discovery is hence best understood as a set of activities rather than a clear cut-phase that is separated by a milestone or gate from building the actual solution.

If we like it or not, failure is an essential innovation ingredient. It’s impossible to successfully innovate without taking informed risks and making mistakes. YouTube, for example, failed as a video-dating site and succeeded by pivoting to video-sharing site; and Google Glass failed as a consumer product and was recently re-launched as a B2B product. As these examples show, you are bound to make mistakes whenever you try something new: You may discover that some of your ideas and assumptions are wrong or that you have executed them wrongly. As individuals and businesses, we should therefore appreciate failure—product success would otherwise be impossible to achieve. But deep in our hearts, many of us dread failure. Why is that?

Most larger companies are great at maintaining existing products and leveraging them as cash cows in order to generate vital business benefits. This often leads to a conservative attitude, protection of the current assets, and focus on operational excellence and flawless execution. In such an environment, product innovation is the exception rather than the norm, and experimentation and making mistakes are discouraged;. In the worst case, such a company experiences Innovator’s Dilemma: It has lost its ability to embrace new opportunities and technologies and can’t keep up with new competitors.

But it would be wrong to say that it’s all management’s fault. As individuals, we sometimes see failure as a threat and consequently shy away from it. That’s partly due to our conditioning—we usually don’t get praised in school for failing, and we certainly don’t get great marks for making mistakes. But I’ve noticed that failure becomes particularly difficult for me if it challenges my self-view. If I identify myself with what I know and do, then failure jeopardises my sense of who I am and how others might perceive me. This restricts me to my comfort zone—I keep doing what I do well—as this feels nice and pleases my ego. The drawback is that I don’t develop and grow, avoid challenging projects, and miss new opportunities.

I’ve also noticed that when I badly want to succeed, I don’t want to be confronted with failure, and I consequently ignore it—sometimes without being aware of it. This makes me prone to confirmation bias, which is the tendency to favour information that confirms our preconceptions, and it puts me in danger of ignoring data that indicates failure. Instead of build-measure-learn, I now get build-measure-deny; instead of inspect-and-adapt, I end up with inspect-and-ignore—which is hardly a recipe for achieving product success.

Luckily, there a number of things we can do to accept and leverage failure, as I discuss below.

Create a Fail-Safe Environment

If there is fear of failure, if people are worried about their jobs and career prospects when they make mistakes, then failure is unlikely to happen. Consequently, learning from failure and successful product innovation are difficult to attain. At the same time, companies must protect their cash cows to generate enough revenue and other business benefits, as I pointed out above. The following techniques make it possible to fail safely and protect mature assets.

Innovation Lab: A dedicated research facility that is tasked with new product development. Many tech companies including Google and Microsoft use labs—which are sometimes also called research centres. The potential drawback is a disconnect with the rest of the company (ivory tower syndrome).

Incubator: A temporary business unit created to bring a new product to life. As soon as the product is launched, the incubator is dispersed, turned into a permanent business unit, or spun off as a separate business. Incubators avoid the ivory tower syndrome of innovation labs. But it can be hard to create the right environment that removes people (temporarily) from their peers and encourages them to think outside the company norms.

Hackathons: A dedicated event where people come together for one or more days to try out new ideas. Facebook’s Like button was conceived in a hackathon, for example. A potential drawback is solution focus—it may be more important to build a cool prototype than to understand if and why people would want to use the product or feature.

20% Rule: Engineers can spend up to 20 percent of their time exploring new ideas. Google Mail and Google Chrome browser were conceived this way, for instance. A drawback is a seemingly high investment in innovation.

Whichever approach you choose, ensure that you create an environment that allows you to fail and learn fast: The earlier you fail, the cheaper the failure tends to be; the impact is less severe, and you will have more options to take corrective actions. What’s more, late failure can be more difficult to accept on a personal level, as you may have become attached to your ideas and find it hard to let go of them.

Change the Corporate Culture

While the techniques above are great to develop new products and features, they accept that innovation and failure are not necessarily the norm—hence there is an innovation lab and there are hackathons, for instance. But when a company wants to emphasise innovation and make experimentation and failure mainstream, these techniques may not be enough. What may be required is a change in the corporate culture—the values and principles that guide people’s actions at work.

One way to do this is to host fuckup nights—please excuse the explicit language. For most companies and products, the path to success is paved with failures and mistakes. Talking about them, however, is usually taboo. At fuckup nights, people share their failures thereby encouraging others to dare to make mistakes and learn from them. Take Otto, a German online retailer, where executive and senior managers have spoken at company-internal fuckup nights and shared their personal failure stories, which I think is great.

Even if your top management is willing to share their failure stories, you may want to consider organising Failure Swapshops—originally created by Luke Williams—for the product people at work or a meetup. I remember attending a Failure Swpashop lead by Adrian Howard at the ProductCamp London in 2015, where the participants were invited to share their failure stories. I was amazed by how open people were and how many mistakes we all make—it was a brilliant and very cathartic session.

Another way to change the company culture is to make failure part of the company values, as Intel has done, for example. Its values recognise that risk taking and failure are unavoidable to achieve success thereby encouraging people to “foster innovation and creative thinking, embrace change and challenge the status quo”. When I worked for Intel—which was admittedly a long time ago—you could and should use the values to challenge your boss, peers, and yourself.

But if you can’t secure executive support to change the company values, do not despair: You can still change yourself thereby acting as a role model and encouraging others to change.

Change Yourself

Changing your outlook on failure is maybe the most important and powerful option you have. What helps me is trying to see failure not as a threat but an invitation to learn, improve, and grow as a product professional and a human being. That’s possible if I don’t let my knowledge, expertise, and achievements define who I am, but rather hold them lightly and embrace a growth mindset.

Failure really is part of life: If we all had not repeatedly tried, failed, and tried some more, we would not be able to walk—let alone speak, read, and write. You should therefore not view yourself as a failure when you fail. While it’s good to care about what you do, you shouldn’t let failure bring you down. This works if you don’t expect success or want it badly. Failure, then, can be a great teacher.

Mindfulness practice has helped me become more aware of my likes and dislikes, and be more at ease with failure. It has shown me that personal change is possible if I am patient and if I’m compassionate towards myself.

Collecting feedback from the right people is crucial to make the right product decisions: If you invite the wrong individuals or if key people are missing, then you are unlikely to receive the feedback you need. You should therefore make sure that you invite the right individuals.

As a rule of thumb, ask those people to attend whose input you need to validate the latest product increment and move the product forward. These are typically your key stakeholders—the people who have an interest in your product and who you need to develop and provide the offering. These may include people from marketing, sales, service and support, and other business units depending on your product and organisation.

I find it helpful to explain to the individuals why they are asked to attend the meeting and what they are likely to see in order to encourage them to participate and to set their expectations.

Collaborate but Don’t Be Afraid to Say No

More than one sprint review meeting I’ve attended was quickly over: A development team member demoed the functionality to confused looking stakeholders with the product owner in the background. Afterwards the ScrumMaster asked if there were any questions or feedback, but the stakeholders just looked at each other, a few said “nice job” and “looks good”, and then people left. The valuable feedback gathered in this meeting was zero.

Therefore, encourage people to actively participate and share their views, ideas, and concerns. Use open-ended questions like “What do you think about the improvements we made to registration feature?” Try to understand why somebody likes or dislikes the product increment. Receiving feedback such as “looks great” may feel good, but it does not offer any new insights. Why does the person like the changes? And is there anything that could be improved further?

Give all attendees the opportunity to be heard. Appreciate their opinions and feedback, even if you disagree or find it difficult to accept them. Remember: The creativity, knowledge, and feedback of the stakeholders should help you make the right product decisions and offer the best possible product.

At the same time, don’t accept that individuals use the meeting to make demands or strike the best possible deal for themselves or their business units. I remember one sprint review meeting where a senior stakeholder literally shouted his demands at the product owner and dev team—which was neither appropriate nor helpful, of course.

As the person in charge of the product, be kind and understanding. But do not let the stakeholders tell you what to do. You own the product and you must have the final say—otherwise you don’t have enough authority and respect.

Don’t be afraid to say no to ideas and requests if they are not helpful and realistic. Use the product roadmap together with the overall product strategy to decide if you should take on a request. In doubt, use the next sprint to test if the idea or request would be beneficial to the users. But remember that it’s virtually impossible to offer a product that pleases everyone.

Ask your ScrumMaster to facilitate the meeting and establish ground rules. This allows you to engage with the attendees and collect feedback without having to moderate.

Consider Splitting the Meeting in Two Parts

Sometimes it’s helpful to split the sprint review meeting into two parts. First, you and the development team get together. The team demoes the product increment to you. Then you give feedback to the team members and determine which items are done and how much progress has been made using, for example, the release burndown chart (as I discuss in more detail below). If you decide to take advantage of just-in-time reviews where you provide feedback on new functionality during the sprint, you may not require this part at all.

In the second part, the stakeholders join the meeting. I find that as the product owner, you are often best suited to present the product increment to the stakeholders: You are likely to better understand how a user would interact with the product and use the new functionality than a development team member. Then collect feedback from the stakeholders to understand if you are creating the right product with the right user experience and features. Ask open-ended questions as recommended above in order to understand why the new functionality is great or why it should be changed, for example.

Splitting the meeting allows you to have a private conversation with the dev team and possibly sort out any disagreements before people from outside the Scrum team join you. This is particularly helpful when you didn’t have the chance to interact with the team during the sprint—be it that you are not collocated with the team or that you were busy visiting users and customers or attending a tradeshow or conference. But do make sure that the development team members attend the entire meeting and are present in the second part. Hearing feedback directly from the stakeholders is invaluable.

Consider Separately Collecting User and Stakeholder Feedback

The original idea of the sprint review meeting is to bring all the right people together and collect feedback from everyone at the same time. If that works for you, then that’s great. Often, though, I find that it is more helpful to separately gather feedback from users and internal stakeholders. Why? Both groups tend to have different perspectives and interests.

Testing product increments with users allows you to understand if the product is likely to do a great job for its target group, if it offers the right user experience and the right features. Discussing increments with stakeholders helps you understand if the product be effectively offered, if it can be operated, marketed, sold, and supported by your organisation.

What’s more, it’s best to collect the user and stakeholder feedback using different techniques: Demoing the product increment to end users makes sense when very little functionality has been implemented. Otherwise, it tends to be more helpful to observe or measure how people actually use the product employing, for example, usability tests and early releases. (See my article “How to Choose the Right Product Validation Technique in Scrum” for more information.)

As these techniques usually require more time than the sprint review meeting offers—it may take several days to collect the relevant data after you’ve released a product increment to (selected) users—this naturally separates collecting the user data from gathering stakeholder feedback.

Bear in mind that users trump stakeholders: If the product is not beneficial to the users, people are not going to employ it (for long), no matter how sellable or serviceable it is, or how much the CEO loves it.

Don’t Decide Hastily

Sometimes, it’s possible to make product decisions straight away in the sprint review meeting and even change the product backlog, as the Scrum Guide suggests. But often—particularly if the feedback has a bigger impact and leads to significant backlog changes—you will benefit from having more time to analyse the feedback, draw the right conclusions, and determine which product backlog changes are required. Additionally, you may not have all relevant data available in the sprint review meeting if you decide to collect user and stakeholder feedback separately, as discussed above.

You should therefore consider separating collecting feedback and data from analysing and actioning it. You may choose, for instance, to have a short, focused product backlog workshop prior to the next sprint planning meeting that offers you the opportunity to objectively evaluate the feedback and update the backlog together with the development team; or you may want to schedule a product backlog session in the next sprint once you have collected enough user data with the help of an analytics tool, as I explain in my article “When should Product Backlog Grooming Take Place?”.

Discuss the Release Progress

Imagine that all the feedback and data suggests that people are going to love your product. But if you are way behind schedule and over budget, then your product may not become a success—it may not even get officially released. It is therefore important that you regularly determine the progress made.

The sprint review meeting is a great opportunity to do this, as you should now be able to tell which items were completed and therefore understand how far you have come. Additionally, the key stakeholders who attend the meeting have an interest in finding out if the new product (version) will be released as planned or if there is a delay, as this is likely to impact their work. What’s more discussing the progress puts the current sprint into context and connects it with the previous ones.

I like to work with the release burndown chart, Scrum’s standard artefact for tracking the release progress and anticipating how the project is likely to unfold. The chart shows how the effort in the product backlog develops from sprint to sprint—the idea being that the effort is reduced or “burned down” over time.

No matter which tool you use: make sure that it helps you understand how fast you are progressing and to make the necessary adjustments—be it adding a UX designer to the team, postponing the release date, or partially meeting the release goal and possibly delivering fewer features than planned.

Possibly the most profound challenge in product management is to understand the needs of users and customers. Without developing the right understanding, our chances of creating a successful product are slim.

While there are numerous techniques available to uncover user needs—think of direct observation, problem interviews, focus groups, surveys, and MVPs, to name just a few—none of them is truly useful, if we do not empathise with the people that will use our product, if we do not get in touch with their feelings and thoughts.

Otherwise, we run the risk of pushing out feature after feature, MVP after MVP, without ever knowing why some features or products stick and others don’t. In the worst case, we build digital products that are harmful and encourage addictive behaviour, as we don’t see the humans behind the analytics data and financial numbers.

Empathy in a Nutshell

Empathy is our capacity to relate to each other on a very fundamental level: to understand other people’s feelings and to take the perspective of the other person. Say a friend tells you how sad she is after splitting up with her partner. Your natural reaction will be to feel sad with her, to mirror her feelings. Or another friend shares with you how happy he is, as he’s found a new job. You are then bound to feel happy for and with him. The best explanation of empathy I have found is the one below.

Sesame Street: Mark Ruffalo: Empathy - YouTube

While it is our nature to empathise, there are some conditions that increase our ability to be empathetic, while others decrease it. The following tips want to help you empathise with users and develop a deeper understanding of their needs.

Empathy Tip 1: Meet users face to face

Meeting real users on a regular basis should be part of every product manager’s and product owner’s job. Unfortunately, that’s not always the case. As product people, we are sometimes shielded from the users by management, sales, or support.

But without meeting the beneficiaries of your product, you cannot truly understand their feelings and needs. In the worst case, you create an ineffective empathy map or persona based on hearsay and half-knowledge, but not on personal experience and insight—which is a common mistake in my experience. And while it’s great to have analytics and quantitative data available, I for my part find it impossible to empathise with numbers.

Therefore, make sure that you meet users face to face and preferably in person, at least once every three months. While a video call call might work, I wouldn’t recommend it if you haven’t met the individual before, as it’s harder to empathise with the person if you are not in the same room.

Empathy Tip 2: Take a genuine interest in the person

Understanding another person requires a friendly, kind, and open attitude. Be respectfully curious about the individual’s thoughts and feelings, no matter if you find the person likeable or not. Now, that’s easier said than done for me, as I can be critical about others and myself. But I know that having the courage to openly engage with a “difficult person“—someone I find challenging to relate to—helps me see the individual for what she or he is: a fellow human being with hopes and dreams, worries and fears just like me.

Additionally, appreciate the opportunity to meet users, and be careful not to view the meeting as a tick-box exercise, as this might instrumentalise the other person: You might be more interested in collecting the right information as quickly and efficiently as possible rather than engaging with the individual. But such an approach significantly reduces your ability to empathise and consequently collect the missing information.

At the same time, be kind to yourself. Recognise that being worried, stressed, tense, tired, or restless will make it harder to be empathetic. If you are not reasonably content and settled in yourself, then it’s hard to reach out and connect with others, as you are likely to be caught up in your own thoughts and concerns.

Empathy Tip 3: Have an open mind and stay present

Most of us are so used to evaluating, analysing, and judging other people’s views, emotions, looks, attitudes, and behaviour that we are hardly aware of it. Unfortunately, a judgemental, critical mind is an empathy barrier. Let’s look at an example.

John, one of the users you are meeting, tells you that the latest update is rubbish. But your data suggests that the majority of users think the opposite. It’s easy then to become defensive and label John’s view as an outlier. While this might be correct, it is a judgement. Thinking that the person’s opinion is non-representative or wrong is likely to prevent you from understanding John’s reason for preferring the old product version and possibly enhancing the latest one.

Alternatively, you might find that John’s feedback triggers a thought process. Your mind wanders and you evaluate how you could fix the issue. You might start identifying improvements for the product, possibly even redesign the user experience, while you are still sat in front of John.

If your mind is critical or not focused on the present, then you lose some of the connection with the other person; you are likely to empathise and understand less. What helps me is being mindful, paying attention to what’s happening inside me, how I respond to what I see and hear, and catch myself before I get lost in my own thoughts and feelings.

Empathy Tip 4: Ask clarifying questions to deepen your understanding

John’s feedback clearly tells us that he does not like the latest product update. But why is that? Why is he unhappy with the product? To deepen your understanding, ask open, clarifying questions.

For example, you might want to say to John: “It seems to me that you are disappointed with the latest update. Can you please share why that is?” This should move on the conversation to uncovering the reason for John’s negative feedback, which is likely to be an unmet need. This in turn may lead to the opportunity to innovate.

Give John the necessary time to answer your question. Tolerate silence and don’t jump in with suggestions (“it’s probably because you wanted …”). Allow yourself to be patient; developing empathy takes time.

Empathy Tip 5: Eat your own dog food

Using your own product will also help you empathise with the users: You are likely to experience the shortcomings virtually every product has, which allows you to better understand the negative feelings and actions that the product might trigger like users becoming impatient or frustrated, and not completing a user journey or possibly stopping to use the product.

While you may want to ensure that your product does a great job for all its users, be aware that you cannot please everyone. Empathy, therefore, may also mean saying no in a kind way so that your product continues to have a clear value proposition and addresses a specific problem for a particular group of people.

“Bring me that horizon,” says Jack Sparrow at the end of the movie The Curse of the Black Pearl while steering his pirate ship into the open waters. While Jack may seek freedom rather than the line that separates earth from sky, he could easily determine how far it is—there is only one physical horizon on our planet, and the distance can be calculated using a standard formula.

But in product management, there are several horizons that need to be considered—how many depends on the product planning model you use. Therefore, before determining timeframes, make sure that you have a suitable model in place like the one below, which I developed while writing my book Strategize.

In the product planning model above, the vision describes the ultimate purpose for creating the product; the product strategy states how the vision will be realised; and the product roadmap states how the strategy will be implemented. The product backlog contains the details necessary to develop the product as outlined in the roadmap including epics and user stories. A sprint goal describes the purpose of a sprint and states why it’s worthwhile to undertake the sprint.

Say I want to create an app that helps people become more aware of what, when, and how much they eat. My vision, then, would be to help people live more healthily; the strategy could be to create an app that monitors their food intake in conjunction with a smart watch or fitness band, and smart food scales. The product roadmap would communicate how the product is likely to grow, stating the benefits it should provide together with desired timeframes or dates. The product backlog might contain epics and user stories like “As Mary, I want to get an overview of my daily calorie intake,” and a sample sprint goal could be “validate that people are willing to share personal data before using the app’s main features” or “finish the dashboard so it can be released”.

Timeframes

With the right planning model in place, you can take the next step and consider appropriate timeframes. The picture below shows the planning horizons I like to work with.

Note that the planning horizon in the picture above becomes increasingly shorter from vision to sprint goal while the planning artefacts become more specific and focused. This is due to a simple but fundamental correlation: the further we look into the future, the less we can see. What’s more, take the numbers stated as recommendations and adjust them to your product. Only look as far into the future as you realistically can—without resorting to speculation or wishful thinking.

As the picture shows, I prefer to work with a big, ambitious vision like “help people eat healthily” that looks three to five years into future and thereby provides a continuity of purpose for everyone involved in developing and providing the product.

When it comes to product strategy, I like to consider the current life cycle stage. For a brand-new product, the strategy should communicate what it takes to get to launch, enter the introduction stage, and serve the early market. After launch, the product strategy should describe how to achieve product-market fit and enter the growth stage. Once that’s happened it should state how to achieve sustained growth, and so forth. This may result in a planning horizon of six to 18 months for your strategy—even though some products require longer to leave a stage. Take the Apple Watch as an example. The product was launched in April 2015, but I am not convinced that it has entered the growth stage.

Product roadmaps benefit from a twelve-months horizon in my experience (assuming the product strategy covers at least the next twelve months). Additionally, I like to include quarterly product goals on the roadmap like acquiring new users, increasing engagement, generating revenue, and removing technical debt. Shared goals create focus and alignment, and they make it easier to understand if the product is providing the desired benefits.

While a product backlog may contain outstanding work for years to come, I find such a backlog unworkable in practice. Instead, I prefer to work with a concise product backlog that is focused on the next roadmap goal, as I describe in more detail in the article “The Product Roadmap and the Product Backlog.” Such a backlog is comparatively easy to update and change—which is particularly helpful for young products.

A sprint goal, finally, should cover the next one to two weeks, guide the daily work of the development team, and set the expectation of the stakeholders.

Re-planning Cadence

While planning ahead is important, it is not enough: Things are likely to change when you manage a digital product (or if you were to sail on a pirate ship, for that matter). You should therefore regularly review your plans and revise them. The following picture shows my suggestions for reviewing and changing the vision, strategy, roadmap, and backlog.

I recommend reviewing and updating the vision when you cannot find a strategy that takes you closer to it, that is, after you’ve pivoted twice unsuccessfully.

Product strategy and product roadmap should be reviewed and adjusted at least once every three months, as a rule of thumb. (This assumes that a validated product strategy is available, that is, the strategy does not contain any big risks.) I like to combine strategy and roadmap reviews to ensure that the two plans are fully aligned and to reduce the meeting overhead.

Last but not least, you should review and change the product backlog whenever new feedback or data is available. This might be on a fortnightly or a daily basis depending on how often you test new ideas and collect the relevant data.

Note that the relationships between the elements in the picture above work in both directions: the product backlog can cause changes to the roadmap, which in turn may affect the strategy. For example, if the feedback from the customers and users indicates that the product does not adequately address their needs, or if the development progress is slow, then this may lead to product roadmap changes. Similarly, larger roadmap changes can cause product strategy adjustments. To avoid inconsistencies, keep all your planning artefacts in synch and involve the right people in the process.

How can you tell if you would benefit from having technical skills as a product owner? To answer this question, I find it helpful to look at how the role is applied. If you manage a digital product that end users employ, such as a web or mobile app, then you usually do not require in-depth technical skills, such as, being able to program in Java, write SQL code, or know which machine learning framework there are and if, say, TensorFlow is the right choice for your product.

But if you look after a technical product—a product that is integrated into a larger offering like a physics engine, which forms part of a computer game—then you will require the appropriate technical skills in order to formulate technical requirements and define software interfaces (APIs). For instance, if you were responsible for a physics engine, then you would probably have to be able to program in C++, use UML, and apply the right software architecture and design patterns.

The same applies if you are a component owner, someone who looks after an architecture building block like a service, component, or layer that forms part of a digital product: You will benefit from having hands-on experience in the appropriate technologies.

Independent of your specific product job, you should take an interest in software technology and be aware of major trends like artificial intelligence (AI) and Internet of Things (IoT). I would argue that every product owner should have at least a basic understanding of core concepts, such as, object orientation, design patterns and architecture principles, as well as agile development practices, such as, test-first, refactoring, and continuous integration.

This knowledge helps you make the right product decisions, for example, investigate how AI and machine learning can improve your product or allocate time for architecture refactoring work. It also helps you empathise with the development team and understand some of the challenges the team members experience whilst designing, programming, and testing the product.

Learning to program can help you acquire the relevant knowledge—I am certainly grateful that I had the opportunity to learn to write code and architect software systems. But do make sure that you focus on your actual job—to ensure that your product creates as much value as possible for the users and your company. It’s more important that you understand the value your product creates for its users, who the product serves, what makes it stand out, and what business benefits it should deliver than being able to know if a layered or service-based architecture is more appropriate, for example.

Additionally, don’t interfere with the development team’s autonomy by making technical decisions, which can be tempting for product owners with strong technical skills in my experience. It’s the team’s job to decide how the product is built, not yours. If you feel that people lack the necessary skills to make the right technical decisions, then discuss this observation with the team in the next sprint retrospective and agree on the right improvement measures, rather than you taking over and telling people what to do.

Finally, recognise that playing the product owner role and working in product management is as exciting as it is demanding. Don’t feel bad if you lack technical understanding. See it as an opportunity to learn and grow, and expand your product management practice.

“You just can’t make up your mind. I really wish that for once, you gave us clear priorities,” Jane said accusingly at the end of the workshop and walked out of the room. [1] It felt like a slap in the face, an unprovoked attack. How could she say something so wrong?

Does this story sound familiar? I certainly find that as product managers and product owners, we sometimes have to deal with pushy, stressed, or unhelpful stakeholders and team members—with people who are just being difficult.

If we reflect on the nature of our work, then this shouldn’t come as a surprise: Product management is as much about people as it is about products. Friction and conflict commonly appear when people from different departments work together. What’s more, innovation and effective teamwork are only possible if we can leverage conflict and disagreement. [2]

Don’t Ignore the Conflict

It would be easy brush aside the issue and forget what Jane said. With so many things competing for your attention, should you really worry about Jane’s remark? But what would happen if you did ignore the conflict?

Chances are that you would feel aversion towards Jane, even if you are not fully aware of it. Next time when you meet, this might cause you to say something you later regret, which would make things only worse. What’s more, tolerating wrong behaviour sets a precedence and creates an unhealthy work atmosphere; disrespect invites disrespect.

Therefore, do not ignore conflict. See it as an opportunity to improve your product management practice and leadership skills. This, of course, is sometimes easier said than done: Addressing the issue requires courage. Jane might a powerful or influential individual like senior management stakeholder. Additionally, you have to be willing to honestly reflect on your own intentions and actions, and be open to change your behaviour.

Regain Your Composure

When exposed to unkind behaviour, it can be hard for me not to lose my calm. But before responding to Jane and telling her what you think, stop and reflect. Become aware of how you are, how you are feeling. Are you disappointed, upset, or angry? If so, then that’s ok. But bear in mind that negative thoughts and emotions cloud your perception; they will make it difficult to have a constructive conversation with Jane.

What’s more, negativity affects your own wellbeing; it makes you unhappy. Holding on to anger, a wise man once said, is like grasping a hot coal with the intent of harming someone else: The only thing certain is that you will get burned. [3] Even if anger, fear, or worries seem to have a tight grip on you, they will weaken and go away if you do not feed them. Acknowledge them, but do not engage and identify with them.

Additionally, bring to mind the positive qualities of the difficult person. Jane surely can’t be all mean and evil. Think of moments when you saw Jane help others, make a constructive contribution, or commit other acts of kindness. Remind yourself that anybody who acts in unskilful ways must be unhappy deep inside. This will help you empathise with the difficult person and develop compassion, rather than villainising the individual and holding a grudge against her. Finally, tell yourself that as human beings, we have all acted in inappropriate ways and said unkind things; I’m certainly not perfect by any means.

Put Things into Perspective

Next, ask yourself why you perceive the person as difficult. What makes the individual so hard to deal with? Why did you respond in the way you did? Why did Jane’s remark make you feel angry or hurt, for example? Was it purely because of what Jane said, or has it something to do with you?

I notice that my own response to unskilful behaviour is particularly strong when deeply held opinions and believes are challenged. If I think of myself as someone who is decisive and knows what’s right for his product, then I am likely to be more affected by Jane’s remarks—independently of her intention. Similarly, I find that when I am stressed or tense, any wrongdoing I experience feels worse than when I am relaxed and content.

Finally, look at the data and calmly consider what actually happened. Jane’s remark might have felt like a slap in the face. But did she mean to be nasty? And did you contribute to the conflict in any way? Was there anything unhelpful you might have said or done to Jane, intentionally or unintentionally? This doesn’t excuse Jane’s behaviour, of course. But it helps put things into perspective and move on from blaming Jane to resolving the conflict.

Respond Skilfully

When you meet Jane to address the issue, approach the meeting with the intent to understand and reconcile, not to win. Conflict resolution is not about getting the better of the other person; it’s about developing a shared perspective on what happened, agreeing on the changes required, and rebuilding trust.

Share your perspective and experience in a constructive way, and be kind: Jane may not be (fully) aware of her actions or their impact on you. At the same time, be honest and firm. Use the I language; describe what you saw and heard, and how it affected you. For example, “I heard you challenge my ability to prioritise and make effective product decision; then I saw you leave without giving me time to respond. I consequently felt angry and disappointed.”

Separate the person from the issue. Don’t blame or attack the other person, don’t generalise (“that’s typical of you”), don’t talk about what other people may have said (“John says so too”), don’t speculate (“it’s probably because you didn’t get what you wanted in the previous meeting”). Listen with an open mind and try to suspend judgement. We all hold a piece of truth.

Offer a helping hand and make constructive suggestions for resolving the issue. Suggest changes that you are prepared make, such as, “I will invite you from now on to the product roadmapping workshops so you better understand the overall constraints we have to take into account when prioritising the product backlog,” or “I will listen more carefully to your suggestions so you no longer feel ignored and side-lined.”

State the positive changes that you wish for, for instance, “it would really help me if you tried to be more patient and understanding,” or “it would be great if you could let me know sooner if you feel your opinion is not heard.”

Remember: While you want to be kind and caring, you are not responsible for the other person’s thoughts and feelings. You can encourage another person to change. But you cannot make someone change her attitude and behaviour.

Move on

If everything works out well, you’ve made up with Jane and agreed on a way forward. What’s then left to do is strengthening the relationship and fully re-establishing the trust that might have been lost. This is achieved by working together as well as socialising, for example, having coffee or lunch together.

If the conversation didn’t go well, consider what the next steps are. Should you talk to Jane again? Should you involve someone who can mediate? Should you escalate the issue? Talking to your manager or ScrumMaster / coach might help you choose the right action.

Notes

[1] Note that Jane is a fictitious character. I assume that the conflict can be resolved by the people involved unlike severe transgressions, such as violence or sexual harassment. If in doubt, involve your manager and human resources.

[2] Tuckman’s team building model, for example, suggests that people have to creatively manage conflict to be able to work together productively.

[3] This quote is often attributed to the Buddha but it may actually be from Buddhaghosa.

The Daily Scrum meeting, sometimes also referred to as stand-up meeting, wants to help the development team manage its work. In Scrum, the team collectively agrees to a sprint goal and is responsible for meeting it. This includes tracking progress of the work on a daily basis and discussing any changes that may be required. The Daily Scrum supports self-organisation by encouraging the team members to talk about:

The progress made by the team members;

What people intend to work on next, and

If anybody needs help—if there are any impediments or blockers.

The Daily Scrum is meant to be a quick meeting that lasts no more than 15 minutes. It should be held at the same place and time every day; I find it’s best to have the meeting in the morning.

Tip #2: Should you attend?

I recommend that you participate in the Daily Scrum at least twice a week as the person in charge of the product. [1] This allows you to understand what’s happening in the current sprint, and if and how you can help. You may find, for example, that some user stories are done and can be reviewed; or you may discover that the team is struggling with some acceptance criteria and requires your input. Additionally, you may want to ask the team to help refine product backlog items or update the product roadmap, for instance. [2]

Be aware that the meeting is not intended to solve any problems. Therefore, don’t turn it into a product backlog or roadmapping workshop. If you hear that the team members have questions about acceptance criteria, for example, then answer them after the meeting. Similarly, if you require the help of the team to work on the product roadmap, then hold a separate workshop.

Additionally, don’t forget to balance your various duties. These include not only working with the development team, but also meeting users and customers, and engaging with the stakeholders. If you religiously attend the Daily Scrum, then check if the balance is still right.

Tip #3: Don’t interfere

Recognise that the meeting is not for you, but for the development team. Refrain from interfering with the team’s self-organisation and do not assign tasks or criticise individuals, as this would damage the team’s autonomy and weaken the commitment. If you are concerned about the sprint progress, then say so in a honest but constructive way. Do not tell the team what to do. It’s up to the team members to manage the sprint and meet the sprint goal, and it’s up to you to manage the product and the entire release (made up of several sprints).

If you find that the team members look at you and tell you what they have done, you know something is wrong: People report the project status to you instead of taking charge of their work. Therefore, share with the team what you see happening and ask people not to address you but each other. Alternatively, stop attending the meeting until you’ve discussed the issue in the next sprint retrospective where process improvements should be agreed (see below).

Similarly, if it’s hard for you not to suggest who should do what or what should be done next, then stop attending the meeting in order to give the team the necessary autonomy to self-organise and take full control of their work. You should also investigate why you find it hard to let go and trust the team to do a good job: Are you anxious to meet an ambitious product goal? Do you doubt the team’s ability to meet the sprint goal? And what can you do to feel more at ease?

Tip #4: Let the ScrumMaster do their job

Know that it’s the ScrumMaster’s job to ensure that the Daily Scrum takes place and that it is effective. If you feel that something is wrong, however, that the team members don’t track their work well, that people don’t attend the meeting or arrive late, or that the Daily Scrum often overruns, for instance, then discuss your concerns with the development team and ScrumMaster in the next sprint retrospective. But don’t take on ScrumMaster duties.

Remember that your job is to manage the product—not the team or process. If you don’t have a ScrumMaster or if the individual is not available or qualified, then recognise this is as an impediment to achieving product success that needs to be resolved—by hiring a qualified ScrumMaster or helping the current one develop and grow.

Notes

[1] If you are in charge of a larger product and work together with other product people like feature or component owners, then you usually don’t attend Daily Scrums. Instead, participate in the Scrum of Scrums (SoS) meeting, a variant of the Daily Scrum, which is often used to facilitate multi-team development efforts. I like to work with daily SoS meetings that take place immediately after the teams’ Daily Scrums and involve a representative from each development team.

[2] Please note that this recommendation is not in line with the 2017 edition of the Scrum Guide. Over the years, the definition of the meeting has changed. Initially, it was an open meeting, but only development team members and ScrumMaster were allowed to talk (see Agile Software Development with Scrum). In the book Agile Project Management with Scrum, the meeting is changed to allow product owners to contribute (see pp. 135 and 141). No matter what the current official definition is, the key to a successful Daily Scrum is letting the development team take full control of the work in the sprint.