Dealing with an Underperforming Development Team

Listen to this article:

What is Bad Performance?

Before I discuss how you can help an underachieving team, let’s briefly explore what good performance looks like, assuming that an agile, Scrum-based process is used. A development team does a good job if the following three conditions are fulfilled:

First, the group reliably meets the agreed sprint goals and delivers product increments that offer a great user experience and exhibit the desired software quality. Second, the team participates in continuous discovery and strategizing, and its members regularly help refine the product backlog. Third, the team observes sustainable pace. The workload and intensity do not affect the team members’ wellbeing.

If one of these requirements are not fulfilled, the team needs to improve their work. Here are three common symptoms of a development team struggling to do a good job: The team repeatedly over commits or delivers buggy software; the team members expect that you, the person in charge of the product, does the product backlog work and writes the user stories; and finally, the team members repeatedly have to work extra hours to finish the work in the sprint.

As the person in charge of the product, you depend on the work of the development team and you are, of course, affected by poor performance. This includes not being able to release working software to (selected) users and customers, finding it hard to reliably forecast the development progress, and possibly getting overworked as you don’t receive the necessary support from the development team. It is hence in your best interest to help the team get back on track. At the same time, you are not the boss, and you cannot tell the team members what to do. What’s more, an agile, self-managing team is collectively responsible for their performance. This can make it challenging to help a development team improve.

---

Share Your Views but Don’t Tell People What to Do

To discuss how you might help a struggling team, let’s use an example. Say that you are working on a new brand-new product. The current sprint has an important goal: to release the product increment to selected users and validate if the functionality offered works for them. Additionally, you’ve invited the senior management sponsor to the upcoming sprint review meeting to secure the individual’s continued support.

But during today’s Daily Scrum meeting, you notice that the sprint progress has been worryingly slow: Plenty of tasks aren’t finished, and some stories haven’t even been started. It seems that the development team is behind schedule and will find it hard to reach the sprint goal. The team, however, does not seem to be concerned.

In this situation, it can be tempting to step in, tell the development team that they must get their act together and possibly even assign specific tasks to individual members. But this would be wrong. You would interfere with and damage the team’s self-management. An agile team is responsible for planning and tracking the work, reviewing the progress on a daily basis, and deciding how the work should be done to maximise the chances to meet the sprint goal. If you stepped in and took control, you would act as a project manager and essentially disempower the team.

But this does not mean that you should be a passive bystander and watch the team fail. If you believe that the development team needs your help, then talk directly to them, for example, after a Daily Scrum. However, ask the team members for their views before you share yours. You might say, for example, “How are things going? Do you think you are on track to meet the sprint goal?” Then attentively listen to what the individuals have to say.

If you are not satisfied with the answers and believe that the team members are not aware of the issue, share your view without judgement and criticism. You might say, for example, “It seems to me that the development progress has been slow. Several tasks aren’t finished, and some stories haven’t been started. Do you think that’s true?”

But leave it up to the team to decide what needs to be done, and do not force your perspective onto them. You might be wrong after all: The team might be doing a great job despite your concerns. If you are unsure if you should say something or not, talk to the Scrum Master who is responsible for helping the team practice self-management, as I discuss below.

---

Take Stock at the End of the Sprint

Once the new product increment is available, you know for sure how much the development team has achieved. Based on a live demo of the increment, you determine which product backlog items have been completed by using the definition of done, the quality criteria every product increment must fulfil. This allows you to understand if the sprint goal was met and if the team did a good job.

If it turns out that the development team failed to meet the sprint goal, then offer your honest feedback. Clearly state what was achieved and what was not. For instance, if the team only managed to complete half of the product backlog items they pulled into the sprint and missed the sprint goal by a mile, then don’t make out that the team’s performance was OK. It was not. The team simply underperformed. I’ve seen Scrum product owners who put up with an underachieving team partly because they hoped things would improve on their own and partly because they shied away from a difficult conversation. But chances are that nothing will change for the better if you don’t openly address the issue.

At the same token, empathise with the development team and speak with kindness. Don’t have a go at the members, and refrain from blaming and judging people. Treat the team as a valued partner and recognise the effort the group made. Additionally, put the performance issue into context: A newly formed team and a significantly changed one are likely to require a few sprints before the members can reliably meet the sprint goals. Similarly, a team dealing with significant technical challenges may struggle to get sprint planning right due to the uncertainty present.

To give helpful feedback and maximise the chances that your message is heard, you might say: “It’s great that you managed to deliver some of the product backlog items. Thank you for that. But I am disappointed that only half of the work is complete and that the sprint goal was clearly missed. I’d like to understand what went wrong, and how we can avoid a similar situation in the future.” If you are upset or angry, then take a few deep breaths and count to ten before you give feedback. If that’s not enough, take a short break and continue once you have calmed down. While it’s perfectly fine to have difficult emotions, acting them out is not OK. I once witnessed a sprint review meeting degenerate into a shouting match. This did not solve anything, of course. Instead, it made things worse, destroyed trust, and damaged relationships.

---

Use the Retrospective to Determine Improvements

Whenever you experience performance issues, use the sprint retrospective to identify and address their underlying causes. For example, you might find that some of the user stories that went into the sprint were too big or lacked acceptance criteria, that the team did not use the definition of done to identify the necessary tasks during sprint planning, that the software development environment was unstable, or that unresolved conflicts resurfaced and slowed down the team.

Do take part in the sprint retrospective. But don’t dominate the meeting and refrain from blaming and judging others. Instead, embrace a contribution mindset: Ask how you can help to avoid that the same problem will arise again. Don’t assume that a performance issue is entirely the development team’s fault. Instead, cultivate an open mind and actively listen to the suggestions of the development team members. You might find, for example, that you did not involve the individuals enough in refining the product backlog. This might have led to big and unclear user stories, which made it hard for the team to meet the sprint goal. Or you might have put pressure on the team and asked them to pull more work into the sprint than they could realistically handle. These two causes can only be fully resolved if you are prepared to change the way you behave.

If a performance issue persists despite determining its causes and implementing improvement measures, then you might have to consider adjusting the team composition. For example, it may be beneficial to break up a team whose members are working on different, unrelated areas within the same product. It might also be necessary to ask a team member who continuously shows disruptive behaviour to leave the team. However, none of these changes should be forced onto the team. Instead, have an open, honest conversation in the retrospective and look for a solution that works for everyone. This creates transparency, gives people the opportunity to contribute, and reduces the risk that individuals end up frustrated and feeling treated unfairly.

Finally, let the Scrum Master facilitate the meeting and suggest helpful ways to unearth underlying causes and derive actionable improvement measures. If you don’t have a Scrum Master or agile coach, find an experienced, neutral facilitator who ensures that everyone is heard, and nobody dominates.

---

Let the Scrum Master Coach the Team

As much as you may want to help the development team, be mindful that you are responsible for managing the product, not for coaching the team. That’s the job of the Scrum Master or agile coach. If you don’t have a Scrum Master, or if the person is not adequately available or qualified, then don’t make the mistake to cover the individual’s work, certainly not on a continued basis. This would cause you to neglect some of your product management responsibilities—like reviewing and updating the product strategy and product roadmap—or sacrificing your health, neither of which is desirable.

Instead, recognise that the lack of a qualified, available Scrum Master needs to be addressed and engage with the decision-makers in the organisation to find a solution. I personally regard it as unfair to ask product people to act as the product owner if the Scrum Master role is not properly filled.

The post Dealing with an Underperforming Development Team appeared first on Roman Pichler.

Dealing with an Underperforming Development Team posted first on premiumwarezstore.blogspot.com

Seven Product Backlog Mistakes to Avoid

The Product Backlog is Too Big

A few years ago, I was asked to help a healthcare company with their agile transition and its impact on product management. One of the challenges the agile transition team was concerned about was the choice of the right product backlog tool, which at first seemed odd to me. But when I was told that the backlog in question had over 40,000 items, I could see that there was an issue.

Admittedly, that’s by far the largest product backlog I have come across to date. But I find it not uncommon to encounter backlogs that range from several hundred to a few thousand items. But such a product backlog is difficult to comprehend, let alone prioritise and update. This is problematic especially for young products and those that experience a bigger change, like a life cycle extension, as their backlogs tend to be volatile and require frequent and sometimes bigger adjustments.

You should therefore strive to keep your product backlog as concise as possible whenever your product faces uncertainty and change—be it market, business, or technology related. The following three techniques will help you with this: First, group related items into themes. Second, keep lower-priority items coarse grained. Third and most importantly, focus the backlog on a specific product goal. Then decline and remove items that do not serve this goal, as I discuss below.

---

The Product Backlog is Too Detailed

Another time, I was asked to help a team of a major charity in the UK whose task was to create a new website for their fund-raising campaigns. The product owner told me that she’d refined the product backlog as well as she could but that the development team were still not happy with it. Looking at the backlog, I noticed that it contained only detailed user stories—no epics or other coarse-grained items.

But an overly detailed product backlog makes it hard to see the wood for the trees: There is simply too much information. This, in turn, makes it difficult to prioritise and update the artefact. What’s more, it is likely to contain speculative and ultimately wrong items, especially when the development effort is characterised by uncertainty and change.

I therefore recommend that you start with an initial product backlog that is intentionally sketchy and incomplete, especially when your product is young or experiences a bigger change. Then let the backlog evolve based on the feedback received from users, customers, and stakeholders. This allows you to minimise the effort to stock the product backlog and to base your product decisions on empirical evidence, rather than gut-feeling.

---

The Product Backlog is Not Appropriately Refined

A while back, I was working with a company that connects consumers in the UK with a tradesperson like a plumber or gardener. Back then, the company was still a startup, and the product owner had asked me to help them address a planning issue: The development team routinely overcommitted and never managed complete all the work in a sprint.

When I was shown around the office, I saw some paper cards on the wall with big, sketchy epics on them, and I asked the product owner if these were part of the product backlog. The individual replied, “No, this is the product backlog.” Given that the backlog did not contain any sufficiently refined, ready items I was no longer surprised that the development team struggled to get sprint planning right.

While you don’t want to make your product backlog any more detailed than necessary, you should ensure that its high-priority items are ready. This requires them to fulfil the following three criteria: First, they are sufficiently clear and understood by the development team. Second, they can be completed in a sprint according to the Definition of Done. Third, they can be tested. Getting the high-priority items ready is best done together with (some of) the development team members, as I discuss below.

---

The Product Backlog is a Wish List

Some product backlogs—like the one with 40,000 items mentioned above—resemble a wish list, a catalogue that contains anything and everything that you might ever need. The trouble with such a backlog is not only that it is usually too big. It also results in a “feature soup,” a product that resembles a loose collection of unrelated features. This leads to a weak value proposition and a poor user experience, which are hardly hallmarks of a great product.

But if these backlogs are so bad, why do they exist? There are two main reasons: First, a lack of strategic alignment and focus, and second, a lack of empowerment. The former means that there is no product goal that guides the decision if an item should be added to the product backlog or not. You might, for example, brainstorm user stories and decide to add all of them. Who knows, they might come in handy at some point in time!

A lack of empowerment causes you, the product owner, to have a hard time declining stakeholders requests and to feel obliged to accommodate them. But if you are not able to say no, your product backlog is in danger of serving individual stakeholders and their personal goals—rather than maximise the value the product creates for the users and the business.

To prevent your product backlog from becoming a wish list, follow these two tips: First, select a product goal and align your product with a strategic plan like a product roadmap (as I discuss below). Second, have the courage to say no. Decline any ideas and requests that are not aligned with the product goal. (See my article Boost Your Product Leadership Power for advice on increasing your authority.)

---

The Product Backlog is Not Effectively Prioritised

Some time ago, I was working with the product manager of a new healthcare product when I suggested to prioritise its features. The individual looked at me surprised and replied, “I can’t. They are all high-priority.” Prioritisation, of course, requires deciding how important an item is. If everything is high priority, everything is equally important. This means in effect that nothing is a priority. But without clear priorities, the development team lacks direction.

If you struggle to prioritise your product backlog, try the following two measures: First, ensure that the product backlog items serve a specific product goal, as mentioned before. Second, select a small set of practical prioritisation factors. The three factors I like to recommend are risk, cost-benefit, and dependencies.

Here is how you can apply them: Initially prioritise the product backlog by risk and consider user, technology, and business-related risks. Assess all backlog items together with the development team and move those to the top that carry the highest risk. This approach accelerates learning, and it avoids failing late when changing course is more costly. Once you’ve addressed the key risks, order the product backlog by cost-benefit, and move those items to the top that give you the biggest bang for the buck, as the saying goes. Finally, don’t forget to consider dependencies whilst using the other two factors. These include dependencies on individual team members and on other teams, as these can influence the backlog prioritisation.

---

The Product Backlog is Not Shared

A few years ago, I was working with a group of product owners based in the Netherlands who wanted their development teams to get better at delivering what they asked for. It turned out that the product owners refined the product backlogs and wrote user stories on their own and then handed off the high-priority items to the dev teams who were based in Romania. The teams did their best to correctly interpret the user stories. But more often than not, they got it wrong, as they had little knowledge about the end users and their needs.

While a lack of collaboration in the situation described might be obvious to an outsider, I find it not uncommon that development teams aren’t properly involved in the product backlog work. But refining, prioritising, and updating the backlog should be teamwork, as shown in the picture below. As the product owner, invite the development team members to work with you on the backlog, and expect that they will support you. If that’s not the case, then discuss the issue in the next sprint retrospective.

Collaborative Product Backlog Workshop

Collaboratively working on the product backlog and co-creating its items offers the following two benefits: First, it leverages the collective knowledge and creativity of the development team, which usually leads to better backlog items—items that are just as detailed as they have to be. At the same time, it allows you as the person in charge of the product to transfer knowledge about the users and their needs to the dev team.

Second, it makes the team members feel valued and respected. It empowers the individuals and increases their motivation to work on the product. People are no longer handed requirements to be worked on. They now contribute to the product decisions and help shape the solution.

If you don’t regularly work on the product backlog together with at least some of the dev team members, then give it a go. Set up a collaborative workshop, be it onsite or online, and ask your Scrum Master to facilitate. Initially, this might require you to spend more time working on the product backlog. But in the longer run, it should reduce your workload. It might even result in the development team being happy to do some of the refinement work on their own.

---

The Product Backlog Lacks Strategic Alignment

A common product backlog mistake and a root cause of several mistakes discussed above is a lack of strategic alignment: The backlog is not systematically connected to a strategic plan like a product roadmap. But without strategic guidance and a clear product goal that governs it, the backlog can easily grow too be, become hard to prioritise, and turn into a wish list. This was also the case for the huge product backlog I mentioned earlier: The strategic objective of the product was unclear, and this made it hard to determine which items should be added to the backlog.

I therefore strongly recommend that you connect your product backlog to an actionable product roadmap that states the value the product should create in form of product goals for the next nine to twelve months, as the picture below illustrates. Sample product goals might be acquiring users, increasing conversation, removing technical debt to future-proof the product, and reducing cost.

Product Roadmap, Product Backlog, and Product Goal

In the picture above, a goal-oriented, outcome-based product roadmap directs the product backlog. This is done by copying the next product goal from the roadmap into the backlog. The goal then helps determine the items that should be included in the product backlog, that is, only those that help meet it. (You can find out more how to the product roadmap and backlog can complement each other in my article The Product Roadmap and the Product Backlog.)

The post Seven Product Backlog Mistakes to Avoid appeared first on Roman Pichler.

Seven Product Backlog Mistakes to Avoid posted first on premiumwarezstore.blogspot.com

Three Qualities of Great Product Roadmaps

Listen to this article:

Goal-oriented (a.k.a. Outcome-based)

Traditionally, product roadmaps are output-focussed plans that map features like registration, search, and reporting onto a timeline. Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders, as the individuals believe that they know when their features will be delivered. But this approach has three drawbacks:

First, a feature-based roadmap makes it hard to secure agreement and create alignment, as stakeholders often compete to get their feature on the roadmap. Second, it overlaps with the product backlog, especially when detailed features are used. This makes the product roadmap more susceptible to change and it increases the effort to update it. Third, the features are sometimes regarded as a commitment rather than a part of a high-level plan that is likely to change. This limits your ability to experiment and learn, to discover the best way to address the user and customer needs and create value for the business.

I therefore recommend applying a different product roadmapping approach and using goal-oriented roadmaps, which are also called outcome-based. As their name suggests, these roadmaps focus on product goals or outcomes such as acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The goals state the specific value a product is likely to create and therefore communicate why it is worthwhile to progress it. This helps align the stakeholders and development teams, as I discuss below, and acquire a budget if required. Lastly, goal-oriented roadmaps are compatible with objectives and key results (OKRs): You can think of the goals as objectives and the other roadmap elements as the key results, as I explain in my article OKRs in Product Management. These benefits make goal-oriented, outcome-based product roadmaps preferable to traditional, feature-focused plans, especially for digital products that exhibit uncertainty and change virtually across their entire life cycles.

If you are looking for a template to create a goal-oriented roadmap, then try my GO product roadmap shown below.

In addition to goals, the template above contains dates or time frames, names, features, and metrics. Note that the features depend on the outcomes: Each feature must help meet a goal and achieve the desired benefit. What’s more, the goals are the primary roadmap elements and are used to secure agreement. You can find more information about the template in my article The GO Product Roadmap.

---

Shared

No matter how well thought-out your product roadmap is, it is worthless if the key stakeholders and the development team members don’t understand and support it. A great way to achieve a shared roadmap is to involve the individuals in the product roadmapping decisions, preferably in the form of a collaborative workshop—be it online or onsite.

Note that collaborative roadmapping does not mean that everybody gets their way or is necessarily super happy with every single decision. It means leveraging people’s expertise to create a product roadmap that maximises the value the product creates and that attracts as much support as possible. While it’s important that you cultivate an open mind, attentively listen to the ideas and concerns of the stakeholders and dev teams, and empathise with them, you should not allow the individuals to tell you what to do. Otherwise, your roadmap may end up being a weak compromise rather than a compelling plan that helps create the desired value for the users and the business.

Have the courage to say no and ensure that the roadmap tells a coherent story about the likely growth of your product. Consider asking your Scrum Master or agile coach to facilitate the workshop and to ensure that everybody is heard and nobody dominates, assuming that a Scrum Master is available. This is particularly helpful when the attendees are new to collaborative decision-making and when they haven’t worked together before. (See my article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams for more information on collaborative decision-making.)

---

Actionable

For a product roadmap to be effective, it must be actionable. The best way to achieve this is to base the plan on a validated product strategy, a strategy whose key assumptions have been tested. Such a strategy should state the user and customer needs, the target group, the product’s stand-out features, and its business goals. Before you develop a roadmap, you should therefore create and validate a product strategy, as the following picture shows.

Additionally, you will have to choose a realistic time frame, a period for which you can anticipate the likely growth of your product without resorting to speculation. My recommendation is to limit the roadmap of a digital product to the next six to twelve months and to regularly review and update the plan—once per quarter as a rule of thumb.

Finally, make sure that your product roadmap does not contain too much detail. Adding, for example, epics and user stories, is a bad idea, as it blurs the line between the roadmap and the product backlog. What’s more, it results in a product roadmap that is difficult to understand, prone to change, and comparatively difficult to manage. You should therefore view your roadmap as a strategic plan, focus it on outcomes and goals, and use it to describe your product’s overall journey. Let the product backlog capture the product details, as the following picture shows.

You can find more information the right relationship between the two artefacts in my article The Product Roadmap and the Product Backlog.

The post Three Qualities of Great Product Roadmaps appeared first on Roman Pichler.

Three Qualities of Great Product Roadmaps posted first on premiumwarezstore.blogspot.com

Product Vision FAQs

Listen to this article:

What is the Product Vision?

The product vision describes the ultimate purpose of a product, the positive change it will bring about. You can think of it as a big, hairy, audacious goal (BHAG)—or a moon shot—that inspires people and offers continued guidance for the next five to ten years.

Say I wanted to create a product that helps people become more aware of what and how much they eat. As the product vision, I could then choose “help people eat healthily” or just “healthy eating.” While the example states the purpose of a new product, I find that a vision is equally beneficial for an existing one.

---

What Makes a Good Product Vision?

A good, effective product vision fulfils the following six criteria:

1. Big and ambitious: It describes a compelling, visionary goal that offers a continued purpose in an ever changing world.
2. Inspiring: The product vision creates a purpose for the people working on the product. It provides motivation and guidance even if the going gets tough.
3. Ethical: A good vision gives rise to an ethical product, a product that truly benefits its users and that does not cause any harm to people and planet.
4. Shared: It unites people, and acts as the product’s true north. 
5. Concise and memorable: The vision is easy to understand and remember. Using slogan—a short, memorable phrase—can be a great way to create such a vision.
6. Not tied to a solution: Despite its name, I recommend keeping the product vision free from assumptions about the actual product or solution. This allows you to pivot, to change the product strategy and the product while staying grounded in your vision.

---

Who Owns the Product Vision?

Ideally, a product vision is collectively owned by the person in charge of a product, the key stakeholders, and the development team(s). This ensures that the individuals support the vision and follow it—rather than paying lip service to it. A great way to foster joint ownership is to develop the product vision together, as I describe in the section “How do I Create an Inspiring Product Vision?” As the person in charge of a product, you should ensure, however, that a meaningful product vision exists and guide the effort to create one.

---

How do I Capture the Product Vision?

As mentioned above, I find it helpful to use a brief statement or a slogan to describe the product vision. This increases the chances that people understand and remember it. An elaborate or verbose vision that looks great on paper but is hard to understand and memorise offers little value.

Additionally, I like to capture the product vision together with the product strategy, as it’s done on my product vision board shown below. The board encourages you to state the product vision at the top and the product strategy underneath it.

You can find more information about the product vision board above in my book Strategize and the article The Product Vision Board.

---

Can the Product Vision and the Company Vision Be the Same?

Yes, the two can be identical. But I recommend using two separate visions—unless you work for an early-stage start-up. The company vision should describe the purpose of the entire organisation, the reason why the business exists. Take, for example, IKEA’s vision to “create a better everyday life for the many people.” The product vision, however, should communicate the ultimate reason for developing and offering a specific product, for instance, IKEA’s app that allows users to design their own PAX wardrobe.

---

Does Every Product Have to Have its Own Vision?

Every product should have a vision, but not every offering requires its own, unique one. Say your product is part of a product portfolio like Microsoft Office. As its products are closely related, I would use one overarching vision for the entire portfolio, a product portfolio vision so to speak. In Microsoft Office’s case, this might be, “help people collaborate in real time.” Word, PowerPoint, Excel, and the other Office products would then share this vision.

---

Do I need a Product Vision and a Product Strategy?

If your vision describes the ultimate purpose for creating the product, you will have to complement it with a product strategy. While the vision is great to inspire the stakeholders and development teams, it is not enough to direct their work. This is where the product strategy comes in. You can think of it as the approach chosen to realise the vision and achieve product success, as the following picture shows.

An effective product strategy should clearly state the needs or user goals that the product will help address or meet, the people who will use and pay for the product, the aspects that set it apart from competing offerings, and the business benefits, which it should generate for the company developing and providing it.

Note that creating a product strategy and validating it—ensuring that it does not contain any major risks or assumptions—tends to be significantly more work than coming up with a product vision. What’s more, the decisions captured in the product strategy are crucial to achieve product success: I view them as prerequisites for deriving an actionable product roadmap with specific, measurable product goals or outcomes that direct the development of the product.

---

How do I Create an Inspiring Product Vision?

The best way to ensure that your vision is inspiring and meaningful for the stakeholders and dev team members is to create it together with the individuals in a collaborative workshop.

To take advantage of this approach, invite the right people to a joint session, be it online or onsite, and encourage the participants to describe the purpose that they associate with the product. Then look for a product vision that is fitting and that everyone can support.

As the vision is truly fundamental, you should take the time required to create an inclusive vision that resonates with everyone. Resist the temptation to shortcut or rush the process. Similarly, don’t allow the most powerful person to dominate and don’t agree on the smallest common denominator. Otherwise, you’ll end up with an ineffective vision.

You can find more advice on collaborative decision-making in my article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams.

---

Does the Product Vision Ever Change?

As a general rule, the product vision should be stable. It should offer continued guidance to for an extended period—at least five years, as I recommended earlier. There are, however, two exceptions to this rule: First, when you create a brand-new product and you cannot find a valid product strategy, you may want to consider adapting the product vision. Second, when your product has been offered for a number of years, you might find that adjusting the product vision is helpful to keep it fresh and meaningful.

Contrast this with the product strategy and the product roadmap. The former will change at least once per life cycle stage, and the roadmap is likely to change several times per year. Both plans therefore benefit from regular reviews. These offer you the opportunity to also assess the product vision and change it if this is turns out to be necessary. To say it with Jeff Bezos words: Be suborn on the vision and flexible on the details.

The post Product Vision FAQs appeared first on Roman Pichler.

Product Vision FAQs posted first on premiumwarezstore.blogspot.com

Tips for Becoming a Head of Product

Be Prepared to Look after People, Not Products

When you become a head of product, you move into a line management position. Consequently, your focus shifts from managing a product to looking after the product people on your team and empowering them to do a great job.

Instead of creating, for example, product strategies and roadmaps and tracking KPIs, you should help the people on your team acquire the right knowledge and develop the right skills so that they can carry out the relevant work on their own. This will allow them to take full ownership of and responsibility for their products, and it will increase their motivation, productivity, and job satisfaction. A great way to do this is to mentor and coach people. For instance, you might show the individuals how they can make effective strategic product decisions, create an actionable product roadmap, and effectively use the right KPIs.

Another key aspect to support the people on your team succeed is to create the right environment for people to succeed. This includes establishing psychological safety, fostering collaboration and trust amongst the product people, establishing clear roles and expectations, which I’ll discuss below, and ensuring that everyone has the right infrastructure and tools available.

Becoming the head of product therefore requires you to let go of your role as a practicing and presumably successful product person and to step away from the many joys and challenges of managing a product. For some people, that’s straightforward. But others find it hard to no longer be actively involved in making product decisions, regularly talking to users, engaging the stakeholders, and working with development teams.

Additionally, being an effective leader requires you to cultivate a genuine caring attitude for the people you want to lead, whether you like them or not. It means that you’ll have to deal with people issues on a regular basis, help and support the individuals who are on your team, constructively address problems and offer advice. To put it differently, to lead means to serve and support others.

If it’s hard for you to let go of being actively involved in managing a product or if you don’t find it rewarding to help and support a group of product people, then becoming a head of product is probably not right for you, at least not at this point in time.

---

Grow Your Leadership Skills

To be able to effectively lead and support a group of product people, you will benefit from having developed strong leadership and people skills, including the following ones:

• Empathy: You are able to reach out with warm-heartedness even to individuals who you don’t agree with and who you find not likeable, value their perspectives, and take a genuine interest in their needs.
• Trust, integrity, and respect: You can earn the trust of others, speak and act with integrity, and create an environment where people feel safe and respected.
• Active listening: You are used to listening to others with the intention to understand, not to answer. You give the other person your full attention, and you keep an open mind whilst hearing what the individual has to say.
• Feedback: You are able to offer constructive feedback so that the other person can receive it and benefit from it. You are also able to skilfully deal with difficult feedback and criticism that others share with you.
• Goal setting: You can lead others through shared goals that create a common purpose and give the individuals the autonomy they need to do a great job.
• Decision-making: You understand how groups can effectively make decisions, and you are able to secure strong buy-in to important product decisions from others, including the stakeholders and development teams.
• Conflict: You can constructively deal with disagreements and conflicts rather than ignoring or suppressing them, or ending up with damaged relationships, bad feelings, and mistrust.
• Time management: You have learnt to effectively manage your time, and you are able to practice sustainable pace.
• Group dynamics: You know what it takes for a group of people to effectively work together, and you are able to help a group of individuals jell.

A great way to develop these skills is to manage a larger product together with a group of product people who you lead—without being their boss. But even if this option is not available to you, guiding a group of stakeholders and one or more development teams will allow you to practice the skills listed above.

---

Ensure that Your Core Product Management Skills are Strong

Being able to effectively lead others is great. But I find that it usually not enough. To be able to guide, mentor, and coach other product people, you should ensure that your own product management “hard” skills are strong and that you don’t have any major gaps in your product management knowledge. This includes the following ten capabilities:

• Formulating an inspiring vision for a product.
• Carrying out the relevant product discovery work and taking into account product ethics.
• Creating and validating a product strategy including market and user research.
• Developing a product roadmap and setting realistic product goals/outcomes.
• Selecting the right KPIs, tracking product performance, and updating the product strategy and roadmap.
• Creating and adapting a business model and generating a financial forecast.
• Creating user models like personas (based on first-hand knowledge of the users and customers).
• Working with the product backlog: Stocking, prioritising, refining, and updating a backlog; capturing product backlog items as user stories.
• Validating solution ideas: Using, for example, product demos, usability tests, and A/B tests.
• Working with data: Selecting data samples, analysing them, and drawing the right conclusions.

As you might have noticed, the list above includes strategic and tactical product management skills. Both are necessary in my experience to effectively support the members of a product management team, understand the challenges they are struggling with, and offer helpful feedback and guidance. What’s more, having solid product management skills shows the people on your team that you are a competent product person. This is likely to increase their respect and trust for you.

---

Gain Experience in Managing Different Products

Having successfully managed different products will put you in a great position to advise and support the product people who work for you. Ideally, you should have managed revenue-generating and supporting products across multiple life cycle stages and events, including launch, product-market fit, and retirement.

The experience of working for different companies can also be an advantage, as this will have exposed you to different company cultures and different ways of practicing product management. I personally benefited a lot from working for Intel as a focused, high-paced tech company in the late 1990ies as well as for Siemens as a much larger and diverse business with different product portfolios and different product management processes.

One of the things I learnt from my time at the two companies is that there is no one right way to practice product management. But I also realised that there are a number of common approaches and techniques that tend to be helpful even in seemingly very different environments.

---

Understand Different Product Roles and Responsibilities

A group of product people will find it hard to work together if roles and responsibilities are not clear. What’s more, it will be difficult for you as the head of product to offer effective feedback and help the individuals develop and grow if it is not clear what’s expected of them. To make things worse, few companies I have worked with had clearly defined product roles. Chances are that you will have to create or improve the relevant role descriptions when you become the head of product.

It is therefore important that you understand common product management roles and responsibilities and that you know how a group of product people can collaboratively manage a larger product. You should understand, for example, what the role of a Scrum product owner is, how it differs from a SAFe product owner, how it compares to a traditional product manager, and which skills an individual requires to be an effective Scrum product owner.

---

Know Your Industry

To be an effective head of product, I find it helpful to understand the industry the company is in. This includes the following four factors:

• The market with the user and customer needs;
• The major players and competitors;
• The dominant business models and revenue sources;
• The main trends that affect the industry.

Having this knowledge tends to make it easier to be a first-time head of product. It means that you don’t have to worry about getting up to speed with new markets, competitors, and products. Having said that, I consider industry knowledge as a plus but not mandatory: You can typically acquire the relevant knowledge comparatively quickly.

---

Carefully Plan the Career Step

As with any bigger career step, it’s helpful to develop a realistic outlook of when you will be ready to apply for a head of product position. To get started, assess your current skill set. Then identify and prioritise any bigger shortcomings that you need to address, and determine the right learning and development measures.

For example, you might decide that as an intermediate step, you aim to manage a larger product and use this opportunity to develop your leadership skills and understanding of product roles. You might also decide to carry out some self-study and read articles and books on (product) leadership or attend a product leadership workshop.

Whatever you do, give yourself the time you need to get ready for the career move. There is no point in rushing into a head of product position and quickly finding yourself out of your depth in the new role. I might put the bar quite high, but recommend at least three to five years’ experience before becoming a head of product and being able to successfully lead a product management team.

The post Tips for Becoming a Head of Product appeared first on Roman Pichler.

Tips for Becoming a Head of Product posted first on premiumwarezstore.blogspot.com

Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams

Be Clear on When to Involve the Stakeholders and Development Teams

You can—and should—make many business-as-usual decisions on your own. Complex and high-impact decisions, however, are best made together with the stakeholders and development teams. There are two reasons for this: First, you usually require people’s expertise to help you tackle complex issues, for instance, to understand technical risks or the impact on the ability to market and sell the product. Second, you need strong support from the stakeholders and dev team members for high-impact decisions in order to ensure that they are effectively followed through. Involving the individuals in the decision-making process show them that you value their input, and it provides them with the opportunity to influence the decision. This, in turn, makes it more likely that they will support and implement the decision.

In practical terms, involve stakeholders and dev teams in decisions that affect the product strategy and the product roadmap—be it that you create the plans or that you make bigger changes to them. Examples of the latter include deciding if you should pivot, address a new market or market segment, retire a product, and if you should replace the product goals or change the dates on a product roadmap. Additionally, include the development team members in product backlog decisions, and always choose sprint goals together.

---

Bring the Right People Together

Once you’ve established that a decision should be made collaboratively, carefully consider who needs to be involved in the decision-making process to ensure that the right decision is made and that it receives the necessary support. Then invite the right people to a collaborative workshop, no matter if it takes place online or onsite. A joint workshop creates transparency; it allows the individuals to understand each other’s perspectives and interests; and it frees you from having to go forth and back between the individual stakeholders and dev teams until an agreeable proposal has finally been found. 

If you are unsure which stakeholders you should involve, then carry out a stakeholder analysis using, for example, Ackermann and Eden’s power-interest grid shown below.

The grid encourages you to divide the stakeholders into four groups, as I explain in more detail in my article Getting Stakeholder Engagement Right. Once you have done this, focus on the players. These are the individuals whose input you need to make the right decision, who help you progress and offer the product, and who are affected by the product and its ability to create value. For a revenue-generating product, this might be someone from marketing, sales, support, and finance.

If you work with several development teams, ask each team to send one or two representatives to the workshop. I find it useful to have UX design, architecture, programming, and testing skills present to make the right decision. And in a scaled environment where you share product ownership, involve the product people who work with you, for example, feature owners.

---

Use a Dedicated Facilitator

When you bring people together to make a decision, getting the individuals to engage in a constructive conversation can be challenging, as you might have experienced yourself. Some individuals might enjoy sharing their ideas so much that they won’t stop talking. Others might be shy and reluctant to contribute, and senior members might expect that their suggestions are followed by everyone. What’s more, you are usually required to actively contribute to the decision and share your expertise, as the person in charge of the product.

I therefore recommend using a dedicated, skilled facilitator who runs the meeting and facilitates the decision-making process. This might be your Scrum Master, assuming that the role is filled, and that the individual has the skills required. The facilitator should establish ground rules, help people embrace a collaborative mindset, create an environment where people feel safe to speak their minds, encourage everyone to fully participate and prevent individuals from dominating, ensure that an appropriate decision rule has been chosen, and guide everyone through the decision-making process. Having a dedicated facilitator can be especially useful in an online workshop where people may need more encouragement to fully participate and stay engaged.

---

Lead by Example

Deciding together becomes difficult when people act in self-centered ways and aim to maximise their personal gain, seek to dominate the discussion, or believe that they know best and that their idea must win. What’s needed to develop an inclusive solution and reach a sustainable agreement is a collaborative mindset.

I therefore recommend that you lead by example, embrace a collaborative attitude, and show that you value the ideas and perspectives of the stakeholders and team members. The following three practices will help you with this: First, show a genuine interest in the perspectives and needs of all attendees—no matter how senior or junior they might be. Second, actively listen to the individuals, give everyone your full attention, and appreciate their contributions even if you disagree. Finally, keep an open mind. While it is important that you have your own perspective and ideas, hold them lightly. Cultivate a receptive and curious attitude and be open to what the stakeholders and development team members have to say. 

Note that attentive listening and open-mindedness do not imply approval. But they make the other person feel understood and appreciated. What’s more, they are likely to free you from being biased towards your own preconceived ideas and help you take full advantage of the collective wisdom of the group in order to make the best possible decision. 

---

Decide How to Decide

Imagine that you are asking the stakeholders and development team members at the end of a collaborative strategy workshop, “Is everyone OK with changing the needs statement in the product strategy?” Because nobody says anything, you assume that everyone agrees with you. But in reality, people are still thinking about the suggestion. To make things worse, it’s not clear who has the final say on product strategy changes. Is it you, the people present, or possibly the management sponsor?

Choosing a decision rule avoids these issues. Such a rule clearly states who decides and how you can tell that the decision has been made. There are four common decision rules that facilitate group decisions: 

• Unanimity: Everyone agrees with the proposed solution and is happy to endorse it.
• Consent: Nobody disapproves and has any meaningful objections.
• Majority and supermajority: More than half of the people are required to agree with a proposed solution. In the case of supermajority, more support is required, such as two-thirds or 75 per cent.
• Product person decides after discussion: Once everybody has been heard and a shared understanding of the different ideas has been established, the person in charge of the product makes the decision.

Note that each rule has its strengths and weaknesses; none is always appropriate. For example, unanimous agreement generates strong support for important product decisions. Achieving it, however, can take a comparatively long time. Contrast this with the rule, product person decides after discussion, which is much quicker to apply. But it may not generate particularly strong buy-in if your decision does not consider the suggestions of the stakeholders and dev team members.

---

Don’t Rush Important Decisions

While it can be tempting trying to quickly solve an issue and make a decision, it takes time to leverage the collective wisdom of a group and solve a complex or high-impact issue. The steps described below will help you guide a group through the decision-making process and arrive at a decision that everyone can understand and support. 

Step 1: Gather Diverse Perspectives

Make sure that everybody clearly understands the issue to be addressed. Then ask people to share their perspectives, come up with ideas, and voice any concerns they might have, for example, by using structured brainstorming. It is essential that everyone can contribute and is being listened to. This makes people feel valued and involved, and it allows you to collect different ideas and perspectives. Resist the temptation to shortcut the process and to prematurely reach agreement at this step. Otherwise, you are likely to end up with a mediocre solution based on familiar options.

Step 2: Build Shared Understanding

Help people understand each other’s views and encourage them to explore the underlying needs and interests. For example, ask the individuals to explain why an idea is important to them or why they feel strongly about a suggestion. What are their motives or concerns? Give the group the time required to develop a shared understanding, and don’t rush this step. If people don’t understand each other sufficiently, then it will be very difficult, if not impossible, to come up with a solution that everybody can accept.

Step 3: Develop an Inclusive Solution

Once the group has established a shared understanding and people know the reasoning and motivation behind the different suggestions, you are ready to develop an inclusive solution. But this does not mean that you should try to please everyone by cobbling together different ideas, nor does it entail brokering a compromise or agreeing on the smallest common denominator. That’s the opposite of what a collaborative decision-making process should achieve. A truly inclusive solution addresses the needs of everyone present, move the product in the right direction, and results in a sustainable agreement—a decision that people will follow through.

---

Use Data to Make Decisions

While it is very helpful to have relevant experience and a solid understanding of the market, don’t make the mistake to blindly trust your gut feeling or to follow the opinion of the most senior stakeholder. Use data instead to make the decision. If you lack the relevant empirical evidence, consider pausing the decision-making process and collecting the data required. 

Say that you are thinking of addressing a new market segment and you are discussing the idea in a collaborative strategy workshop. Some of the attendees, including yourself, have experience in offering products to this segment and are in favour of developing a new product variant for this target group. But if you haven’t done any specific product discovery work and lack data to support this view, I recommend pausing the decision-making process and carrying out the necessary discovery work, for example, interviewing prospective users, and building a throw-away prototype to test your idea. Otherwise, you’ll risk deciding based on experience and beliefs—which may or may not result in the right course of action.

---

Secure As Much Buy-in As Possible but Do Not Allow Stakeholders to Dictate Decisions

When involving stakeholders and development teams in a decision, it’s natural to try to generate as much buy-in as possible. While I can’t emphasise enough how important it is to attentively listen to the individuals and appreciate their perspectives, ideas, and concerns, you should not make the mistake of trying to please people or to allow individuals to dominate the decision-making process. 

Instead, search for a decision that maximises the value your product creates and at the same time, is inclusive and attracts as much support as possible. But do not agree to a weak compromise. Deciding together does not mean that everybody gets their way or is necessarily super happy with every decision. It means leveraging people’s expertise, ideas, and concerns, creating a shared understanding, and finding an appropriate solution that attracts as much support as possible.

The post Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams appeared first on Roman Pichler.

Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams posted first on premiumwarezstore.blogspot.com

Five Product Owner Myths Busted

Myth #1: The product owner must ensure that the stakeholders are satisfied

Stakeholders can be powerful and influential individuals. But the value a product creates is ultimately determined by its users: No product will be successful in the long run if it does not solve a specific user problem, create a tangible benefit, or help the users achieve a specific goal. While internal stakeholders such as marketing, sales, and support play an important role in successfully offering a product, it would be wrong to try to please them and to say yes to all their ideas and requests. In the worst case, you’d end up with a product that implements the stakeholders’ requirements but does not effectively address the user and customer needs.

At the same token, ignoring the stakeholders or excluding them from important product decisions is not helpful either. Instead, you should engage the stakeholders, leverage their expertise, and generate as much buy-in as possible, as I explain in more detail in my article “Stakeholder Management Tips for Product People.” But do not allow people to dominate and tell you what to do, and don’t agree to a weak compromise. As the product owner, then you should own the product on behalf of the company and be empowered to have the final say, particularly if no agreement can be reached.

---

Myth #2: The product owner is a tactical role focused on managing the product backlog

In Scrum—the framework that gave birth to the product owner—the role is responsible for maximising the value a product creates for the users and for the business. This requires full-stack ownership: having the authority to make strategic product decisions in addition to tactical ones. Consequently, a Scrum product owner should own a product in its entirety—from the product vision to the product details. The individual should carry out product discovery and strategy work in addition to taking care of the product backlog work.

But the situation is different for product owners in the agile scaling framework SAFe. The framework uses its own product owner role, which is different from the one in Scrum. The SAFe product owner is tactical in nature and focuses on working on the product backlog and guiding the development teams. The strategic work is taken on by another role, the SAFe product manager. Splitting product ownership and using a strategic and tactical role is a common scaling technique—although not necessarily the most helpful one, as I discuss in more detail in my article “Scaling the Product Owner.” The following picture summarises the difference between the Scrum and SAFe product owner roles.

Be therefore clear which product owner role you play and if you are a Scrum or a SAFe product owner, as your authority and accountability will significantly differ. I have always regarded the Scrum product owner as an agile product manager, and I find it an unfortunate mistake that SAFe use the same name for its tactical product role. This has created more confusion and increased the misconceptions of the role.

---

Myth #3: The product owner is responsible for the team performance

An agile development team does a good job if the memebers can reliably meet the agreed goals and create software that offers a great user experience and exhibit the desired quality. As such a team is a self-managing group, the members are expected to jointly plan the work, decide how it is carried out, track the progress, resolve any disagreements and conflicts, and practice sustainable pace to stay productive and motivated.

As it takes time for group of people to become an effective self-managing team and learn to make realistic commitments, the dev team needs a Scrum Master or agile coach who supports and advises them. This includes showing the dev team how agile processes can be applied and suggesting specific techniques, facilitating meetings, and teaching people how to constructively deal with conflicts. In other words, the Scrum Master is responsible for helping the team do a good job.

But as the product owner, you should focus on the product, not the team and the process. That’s usually challenging enough. Don’t make the mistake to cover the Scrum Master’s work over an extended period, as this will either cause you to neglect some of your core responsibilities or sacrifice your health—neither of which is desirable, of course. If you lack a Scrum Master, or if the individual is not sufficiently available or qualified, then consider what you can do to address this issue. Sometimes, it’s best to make the problem visible rather than carrying out some of the Scrum Master’s tasks and thereby masking the issue.

Additionally, don’t make the mistake to interfere with the work of the development team. For example, it’s a bad idea to tell people what to do in a sprint or to start assigning tasks to individuals. This damages the team’s self-management; it takes away ownership from the group; and it makes the dev team dependent on you as the person who sorts out their problems for them.

While you are not responsible for the team performance, you should, of course, care about the development teams you work with and offer helpful feedback and guidance. A great way to resolve any performance issues is to address them in the sprint retrospective. Dig down to the root causes of the problem and explore how you can help improve the situation. This might include involving the team members in continuous product discovery work, spending more time jointly refining the product backlog, or making yourself available to answer urgent questions and review finished work results during the sprint.

---

Myth #4: The product owner is responsible for writing user stories

User stories are a popular technique to capture end-user functionality. But as product owner, you are not a user story scribe or a product backlog manager. Refining the product backlog and writing user stories is teamwork: The development team members should actively contribute to removing, changing, and adding backlog items, as well as breaking larger stories into smaller ones. You might even delegate some of the refinement work to the dev team, assuming that people are happy and appropriately skilled to take it on.

But it is important that you don’t neglect the product backlog work, as the following story shows. A few years ago, I worked with an organisation that has become a leading provider to hire trusted handymen in the UK like plumbers and electricians. Their product owner asked me for help telling me that the dev team would always over-promise and then under-deliver. After looking at the product backlog—which consisted of a collection of adhesive notes on an office wall at this time—I quickly realised why the team was struggling so much: The backlog contained only epics, big, coarse-grained user stories but no detailed, ready items. Development teams, however, need sufficiently detailed product backlog items to be able to create a realistic forecast for what can be done in a sprint and succeed in meeting the sprint goal. If the items are too big and coarse-grained, most teams will struggle.

Therefore, strike the right balance between strategic and tactical work and spend enough time working on the product backlog together with the development team members. As the product owner, it’s your responsibility that the work required to progress the product and reach the (next) product goal is adequately captured in the product backlog. Such a backlog has enough “ready” high-priority items to guide the work of the development team and to allow its members to create a “done” product increment—executable software that is tested and documented and that could be released.

---

Myth #5: It’s the product owner’s job to get the project delivered

Unlike traditional approaches to software development, Scrum does not offer the role of a project manager. It can therefore be tempting to view the product owner as a project manager substitute. But this would be a mistake. Project management is collectively practiced in Scrum rather than carried out by an individual. What’s more, the product owner is a product management role responsible for managing the product and achieving product success—not for delivering a project. This requires the product owner to look after the product on a continued basis and manage its life cycle—or at least large parts of it. To put it differently, you can think of the product owner as a product life-cycle manager, which encourages decisions that result in sustainable growth and consider the product’s longer-term impact on the users and the business. The picture below illustrates this concept.

The picture above shows how a product might create value over time together with three key events: launching the product, achieving product-market fit, and retiring the product (end of life). Only once it has achieved product-market fit (PMF) and entered the growth stage, has a product started to become successful. A product owner should therefore look after a product at least until PMF, preferably longer.

Contrast this with the job of a project manager who is responsible for delivering a project to an agreed scope on time and on budget. Once that’s been achieved, the project manager’s work is done, and the individual often moves on and works on another project, which might progress a different product. A project manager is therefore focused on a comparatively short-term effort instead of a longer-term outcome.

Therefore, avoid being a project owner but aspire to manage your product for an extended period, ideally for its entire life cycle. This does not imply, however, that you should not care about meeting a specific product goal in a realistic timeframe on an agreed budget. The opposite is the case: Use the release planning tools and techniques that work for you to track and guide the development progress. But create a continuity of purpose by working with a product roadmap like my GO roadmap that captures the specific outcomes the product is likely to create in the next six to twelve months.

The post Five Product Owner Myths Busted appeared first on Roman Pichler.

Five Product Owner Myths Busted posted first on premiumwarezstore.blogspot.com