Listen to the audio version of this article:

Product Strategy and Change

Strategy means different things to different people, so let me briefly share my definition. A product strategy describes the approach chosen to make a product successful. It achieves this by stating the product’s target users and customers, the value proposition, the business goals it should meet, and its standout features. Such a strategy facilitates effective product discovery and product delivery. To put it differently, it’s virtually impossible to determine the right features and capture the right user stories if you don’t know who the users are and why they would want to use the product.

Despite its importance, product strategy is not always effectively practised. A common issue is seeing it as a fixed plan that simply needs to be followed once it’s been agreed. But this only works if the product and market are stable and experience little change. For digital products, this is hardly ever the case in my experience. New technologies alone introduce change and uncertainty—think of the Internet of Things, Blockchain, machine learning, and generative AI, for example. In environments that experience volatility, uncertainty, complexity, and ambiguity (VUCA), the idea that the product strategy is set in stone is fundamentally flawed. Borrowing from Dwight D. Eisenhower, we could say, “Strategy is worthless. Strategizing is everything.”[1]

A Stream, Not Drops

To avoid that the strategy becomes quickly outdated, I recommend establishing a continuous strategizing process. Rather than practising strategy in drips and drops, you should think of it as a firm part of the product team’s job, a workflow that needs to be attended to on an ongoing basis—much like continuous product discovery and product delivery.[2]

By connecting the strategy stream shown in Figure 1 to the product discovery and product delivery work, you ensure that the strategy guides the discovery and delivery activities. At the same time, insights from the development work are used to inform strategic decisions and help adapt the strategy.[3]

Let It Flow

To help you successfully establish a continuous strategizing process, I’ve created the approach shown in Figure 2, which I’ll discuss below and in the following section.[4]

To establish a continuous strategizing process, you must allocate enough time so you can actually carry out the work. I find that spending one hour per day on continuous strategizing works very well for some people. Others prefer to carry out the necessary work once or twice per week.[5] Whatever your preference is, spend at least half a day per week on product strategizing so you can spot opportunities and threats at an early stage. This way, you’ll avoid nasty surprises like a competitor leapfrogging you with a new product or killer feature, and you are more likely to notice early warning signs like declining sign-up rates, increasing churn, or a growing number of support calls.

Additionally, schedule regular collaborative strategy reviews—at least once per quarter—and invite the key stakeholders and development team members to them. These reviews help you see bigger trends. By involving stakeholders and development team representatives you can leverage people’s expertise to assess and evolve the product strategy. What’s more, a collaborative approach helps you create alignment and secure buy-in. While I do recommend that you schedule the reviews well in advance, you should, of course, not wait for the next review if there are new developments that need to be urgently discussed. Instead, hold a collaborative review as soon as possible.

To Adapt, or Not Adapt, That is the Question

To determine if the strategy has to be adapted, I recommend using the five factors shown on the right-hand side of the diagram in Figure 2. Let’s take a look at them.

1. Performance: What do the key performance indicators (KPIs) tell you about the value the product is creating? Does the data show positive, flat, or negative trends? What conclusions can you draw from the analysis? How can you increase the product performance? Are the indicators you are using still relevant, or should they be changed?
2. Trends: Are there any new technology, regulatory, or social developments that will affect your product? Do they offer an opportunity to innovate, for instance, to add, enhance, or remove features?
3. Development insights and product roadmap: Are there any significant learning from the product discovery and delivery work? Has the product roadmap changed? Do the changes indicate that the current product strategy has to be adapted?
4. Competition: Are your competitors launching new products or features? Are there new market entrants? Is your product still sufficiently differentiated and does it still stand out from competing offerings?
5. Business and product portfolio changes: Are there any business developments that affect the product strategy? For example, has the business strategy changed or have key people left? Has the product portfolio strategy changed and if that’s the case, do these changes necessitate any adjustments to the product strategy?

Considering the five factors above will give you a sound understanding if there is a need or opportunity to change the product strategy.[6]

Time is of the Essence

There is no free lunch, and continuous strategizing requires time, as mentioned before. Time, however, is a very rare commodity for product people, and it can be tempting to deprioritise and postpone the strategizing work to deal with more urgent tasks like addressing sales and support requests or answering questions from the development teams. Unfortunately, this will most likely lead to more, unplanned work in the future. In a sense, strategizing is like riding a bicycle or driving a car: If you don’t look ahead, you’ll end up in the wrong place. Even worse, you might crash.

The purpose of using a product strategy is to be proactive: to see opportunities and threats early on so you can respond to them rather than finding yourself with your back against the wall trying to desperately catch up with the competition. I therefore recommend that you schedule and ringfence the strategizing work. Block the necessary time in your calendar. Delegate or eliminate other less critical tasks to free up time if that’s required, for example, by empowering development teams to determine detailed functionality on their own.

Notes

[1] I’m certainly not the first person to note that strategy must adapt when uncertainty increases, see, for example, Rita McGrath’ work. I find it still rather common, though, that established businesses generally see strategy as a solid plan that stays unchanged for an extended period—sometimes as long as three to five years. This explains, at least partly, why product strategy is not practised more effectively.

[2] I follow Marty Cagan and Teresa Torres in viewing product discovery as a workflow rather than a phase or stage. Note that this perspective is in line with an agile development framework like Scrum. In Scrum, the product backlog is emergent. Features and functionality are discovered on a continued basis, see, for example, my article The Product Backlog as a Learning Tool.

[3] For simplicity’s sake, I’ve combined discovery and delivery in a single stream instead of showing two separate but connected workflows. Additionally, note that for brand new products and larger product updates, you will benefit from practising a second type of strategy work, which I call time-boxed strategizing, see my article A Brief Guide to Product Strategizing.

[4] I first introduced the elements shown in Figure 2 in my book Strategize, 2^nd ed.

[5] Note that the amount of uncertainty and change present will impact the strategizing effort: A young product requires a higher effort compared to an older, mature one. Additionally, the frequency at which the data you collect becomes available will determine how often you can carry out continuous strategizing.

[6] Note that I am not advocating changing a strategy for change’s sake. If the five factors listed do not suggest that you would benefit from adapting it, then you should leave the strategy as it is—at least for now. The maximum period a product strategy is stable for is a product life cycle stage, as I explain in more detail in my book Strategize.

Listen to the audio version of this article:

What Is a Product Portfolio Strategy and Why Does It Matter?

A product portfolio strategy is a high-level plan that helps you maximise the value a group of products creates. It achieves this by setting overarching goals for the entire portfolio. These guide and align the strategies of the portfolio members, as Figure 1 illustrates.

In Figure 1, the strategies of the individual products—Word, PowerPoint, and Excel—implement the Office strategy. Their visions, target groups, needs, standout features, and business goals must comply with the overall portfolio strategy.[1]

Product Portfolio, Product Family, and Product Line—What’s the Difference?

A product portfolio is a group of products. These might be end-user-facing or internal ones like a software platform, for instance; they might directly generate revenue or support commercial offerings. Larger companies often have several portfolios; early-stage startups, in contrast, usually have a singleton one—it consists of just one offering.

A product family is commonly defined as a group of related products. You can therefore view it as a cohesive product portfolio—a portfolio whose members have related value propositions and/or business goals, for example, Adobe Creative Cloud and Microsoft Office.

A product line is a set of product variants. You can think of Microsoft Visio as a product line, as it is offered in three versions at the time of writing—basic, standard, and advanced. Another example is YouTube, which is available in three variants—standard, premium, and kids.

Which Specific Information Should the Portfolio Strategy Contain?

An effective product portfolio strategy should contain five elements—an overarching vision that describes its purpose, the positive change it should bring about; the markets and market segments the portfolio serves; the overall value it creates for the users and customers; the business benefits it helps achieve; and the type of products it contains with the capabilities that set them apart from competitors.

To make this more concrete, let’s explore how the Microsoft Office strategy might be captured.[2]

If you are familiar with my work on product strategy, you’ll recognise the structure I’ve used in Figure 2: It is based on the Product Vision Board—the tool I’ve developed to capture a product vision and a product strategy. This means that you can apply my strategy approach not only to individual products but also to your product portfolio.

To get started, create your own Portfolio Vision Board by downloading and adapting the Product Vision Board or by recreating it in your favourite tool. Please make sure, though, that you state the author and source of the Product Vision Board as well as the CreativeCommons BY-SA license on your derived portfolio board—like I did in Figure 2. If you haven’t worked with the Vision Board, then read the article The Product Vision Board and watch the video Product Vision Board Introduction.

But despite the structural similarity between a portfolio and a product strategy, there is an important difference: Due to its nature, a portfolio strategy has to be bigger and less specific than a product strategy—it covers several products and not just a single one. This means that its target group, needs, standout features, and business goals are significantly less specific than those in a product strategy.[3]

How Does the Product Portfolio Strategy Direct the Product Strategies?

Now that we understand which information a portfolio strategy should contain, we can take a closer look at how it guides the strategies of the products it contains using Office as an example. The Word, PowerPoint, and Excel visions have to either support the Office vision or, which is my preference, they inherit it. This way, they share the same purpose—“to enable individuals and organisations to get things done.”

Additionally, the target groups of Word, PowerPoint, and Excel have to be subsets of the portfolio target group. Similarly, the needs captured in the individual strategies have to help meet the needs in the portfolio; the standout features of Word, PowerPoint, and Excel have to address the needs stated in the Office strategy; and their business goals have to help achieve the portfolio ones. Figure 3 illustrates this relationship.[4]

Following this approach ensures that the portfolio and product strategies are closely aligned. To put it differently, the portfolio strategy sets the stage for the product strategies; it guides and constrains the strategic decisions of the portfolio members.

How do Product Portfolio Strategy and Product Portfolio Management Relate?

As its name suggests, product portfolio management is the process of managing a group of products. This includes analysing a product portfolio using a tool like the Product Portfolio Matrix, creating and updating a product portfolio strategy, and adjusting the portfolio. The latter includes harmonising the strategies and roadmaps of the portfolio members, resolving dependencies, coordinating major releases (if required), as well as adding and removing products.

As this description shows, simply creating a product portfolio strategy is not enough. You also have to establish an effective portfolio management approach. Part of this process should be regular portfolio strategy reviews. I recommend holding them every three months and considering the portfolio performance, changes in the competitive landscape and business strategy, new trends, and modifications of the strategies of the portfolio members.

The product portfolio strategy is therefore far from being a fixed plan. Just like a product strategy, it is best understood as being malleable and changeable. As Dwight D. Eisenhower famously said, “Plans are nothing; planning is everything.”

Who Creates and Manages the Product Portfolio Strategy?

Carrying out portfolio management and creating and evolving a portfolio strategy requires expertise and time. To ensure that the work gets done, you have two options:

First, use a dedicated product manager. The individual should have a track record of successfully managing products similar to the ones contained in the portfolio. Additionally, they‘ll benefit from having the right leadership skills, be able to guide a group of product people, collaborate with senior stakeholders, and engage with senior management.

Second, ask the head of product to carry out the portfolio management work in addition to their other duties—as long as the individual has the necessary expertise and does not become overworked.

No matter, which option you choose, it would be a bad idea if a single person made all portfolio decisions on their own. This would waste the knowledge and creativity of the people working on the individual products. What’s more, it might cause poor alignment and weak buy-in. I therefore recommend a collaborative approach that involves the following individuals:

• The product portfolio manager (who might be the head of product);
• The individuals managing the products contained in the portfolio;
• Development team reps which might include a UX designer (for end-user-facing products), an architect/programmer, and a tester/QA engineer.
• Key stakeholders, for example, a sales rep, marketer, and customer support team member.

These individuals form a product portfolio team like the one shown in Figure 4.

The team in Figure 4 is similar to a product team but it operates at a higher level. What’s more, the portfolio team should not only create a portfolio strategy but also collaboratively review and adjust it on a regular basis.

To staff the team, I recommend asking the dev teams and various key stakeholders involved in progressing the individual products to nominate representatives. This ensures that the team members are motivated to help with the portfolio management work. Additionally, keep the team stable to facilitate trust-building and collaboration and avoid handoffs and loss of knowledge.

How Can You Get Started with a Product Portfolio Strategy?

My experience suggests that it’s usually best to first able to create and evolve a strategy for a single offering before you move up a level and employ a product portfolio strategy. Once you have established an effective product strategizing approach—which often is challenging enough—you’ll be in a great position to transfer your learnings onto the portfolio level.

To remind yourself of the advice shared, download the infographic below by clicking on the image.

Notes

[1] The article is based on my work with different clients in different industries using different product portfolios. I use Microsoft Office, officially called Microsoft 365 at the time of writing, as a well-known example of a product portfolio, which you hopefully can relate to—even if you use an alternative like Google Workspace or Apple iWork. Note that it’s unknown to me how Microsoft manages the Office suite, and I don’t claim that the company uses an approach like the one described in this article.

[2] Note that the sample strategy shown in Figure 2 is based on my research; it is not an official description of the Office strategy employed at Microsoft.

[3] You therefore cannot apply the checklist I have developed for the Product Vision Board to the Portfolio Vision Board.

[4] Figure 3 uses a single product strategy for simplicity’s sake.

Listen to the audio version of this article:

Make Time to Keep up with Technology Trends

As new technologies come and go, it’s important for you—the person in charge of the product—to stay on top of the developments. You should be aware of new trends, be able to make an informed guess if they are likely to impact your market and product, and decide if a technology needs to be further investigated. This usually doesn’t require in-depth technical skills like being able to write code or understand how a specific machine learning framework is used. But you should take an interest in software technology, and you should have a basic understanding of how your product is currently built.

To make this more concrete, let me give you a specific recommendation: Spend 30 minutes per week on discovering new software trends and learning more about those that might affect your product. You can do this, for example, by reading technology newsletters, listening to tech podcasts, and talking to development team members, especially those who have a sound understanding of software architecture and technology.

Encourage Regular Technology Research and Experimentation

It’s not uncommon for me to see development teams who work flat out to enhance features and offer new ones. But if that’s all they do, if there is no time to explore new technologies, then you take a big risk: The development team members may not have the skills to take advantage of an emerging technology.

Say that a competitor product just started offering personalised recommendations, and you’d like to be able to do the same. You talk to the development team, and the team members suggest that machine learning is likely to be the right solution. But if nobody has had time to learn about the technology in general and research specific machine learning frameworks, you’re probably months away from offering a similar feature. Instead of giving your product the edge, you’ve been leapfrogged by a competitor—a situation you most certainly want to avoid.

It is therefore important that you give the development team members the necessary time to discover and explore new technologies, build prototypes, and understand if and how a technology is likely to benefit your product or possibly threaten it. As a rule of thumb, development teams should be able to spend at least one day per month on technology research and experimentation. The following four measures will help you with this.

• Gold cards: Development teams set aside time in a sprint for technology research and prototyping by adding dedicated, so called “golden” cards to the sprint backlog.
• Research sprints: You focus an entire sprint on technology exploration. You might vary the sprint length and possibly use a shorter, say, one-week iteration. This can be helpful to tackle a more complex challenge like researching and testing different machine learning frameworks.
• Hackathons, also referred to as hack days: People come together for one or more days to collaboratively explore new ideas and create prototypes. Facebook’s Like button was conceived in this way, for example.
• 20 percent rule: Developers can take up to one day a week to experiment with new ideas and acquire new skills. The Google Chrome browser and Gmail were created this way, for instance.

Use the approach that works best for your team and organisation. Be supportive and don’t expect that every experiment will be a success. Instead, be prepared to experience plenty of failures where the team learns that a technology is not useful for your product, at least not in the near future. See the exploration work as a way to future-proof your product and mitigate the risk of missing out on an opportunity. This will not only benefit your product. It will also have a positive impact on team morale and productivity.

Adapt the Product Strategy to Respond to New Technologies

Finally, you should systematically assess the impact of a new technology on the product strategy and determine if it has to be changed. A new technology might help you capture more market share, for example, and it might extend the life cycle of your product. Think about how smartphones have evolved over the years to stay desirable, for instance, by introducing AI-enabled virtual assistants and face recognition.

I recommend that you assess the strategic impact of a technology in the form of regular, collaborative product strategy reviews. Hold these workshops at least once every three months and invite development team members and key stakeholders to them. Answering the following four questions will help you understand if a strategy change is needed:

• Will the technology help you address an existing need in a better way? Or will it help you satisfy a new one?
• Will it better serve an existing target group, or will it help you reach out to a new market or market segment?
• Will the technology help you better differentiate your product? Will it help you create new standout features or strengthen existing ones?
• Will it affect the business goals? Will it, for instance, require a bigger investment and reduce profitability or will it increase revenue and drive down cost?

To correctly answer these questions, you must have spent the necessary time to scout new technology trends, and maybe more importantly, the development team members must have had the opportunity to carry out the relevant research and experimentation work.

Don’t forget that you want to play a proactive game where you respond to technology opportunities and threats early on—instead of being reactive and driven by what your competitors do.

Listen to the audio version of this article:

1 Complement Scrum with a Product Strategy Process

Scrum is a simple framework that helps teams develop successful products. It achieves this by using sprints to create product increments, collecting feedback from users and stakeholders, and adapting the product with the insights gained.[1]

As simple as this sounds, there is a catch: To create value with Scrum, you must understand who the users and customers are, why people would want to use and pay for the product, which business benefits it should generate, and, in the case of commercial products, which features differentiate it from competing offerings. Otherwise, you might ask the wrong people for feedback on the increments and hence draw the wrong conclusions. What’s more, you’ll struggle to determine the right product backlog items. How can you capture the right user stories, for instance, if you are unsure who the users are and why they want to use the product?

You should therefore do just enough product work before you start using Scrum and before you add any items to the product backlog. But don’t stop there. Continue the discovery and strategy work while the product is being developed. This includes interviewing and observing users, using key performance indicators (KPIs) to track the value of the current product version, keeping an eye on the competition, and monitoring market trends.[2]

If this sounds complicated, then think about common everyday activities like riding a bicycle. Before you can set off, you first have to consider where you want to go and how you will get there—much like the initial discovery and strategy work I mentioned. To move forward, you’ll have to pay attention to the execution: push the pedals, keep your balance, and change gears. But this is not enough. To get to your destination safely, you’ll have to continuously look ahead, avoid obstacles, and possibly adjust the route.

Scrum is like a bicycle; it helps you move forward. But it doesn’t tell you where to go and how to get there—that’s what the strategy and discovery work does.

2 Use Scrum for Products that Experience Uncertainty and Change

Scrum is often seen as the standard way to create digital products, and I have met more than one company where the product managers were told to be agile and do Scrum. But like any tool, Scrum has its benefits and limitations.

I find that the framework is best suited for products that are affected by a significant amount of uncertainty and change. These are typically brand-new and young products as well as products that are experiencing a bigger change, for example, to extend their life cycle by addressing a new market segment or by replacing some of the technologies.

But if your product is in a steady state, for instance, if it is mature, and you focus on incremental enhancements and bug fixes, then you may find it more beneficial to use a Kanban-based agile process instead of Scrum.

To put it differently, there is no one right way to develop products and deliver solutions—just like there is no single bicycle that is perfect for every terrain. A road bike, for instance, is great for riding on smooth surfaces. But a mountain bike is better for riding offroad.[3]

3 Look beyond the Product Backlog and Use Additional Product Management Artefacts

The product backlog can be a great tool to capture the outstanding work to deliver a product. But it’s not enough on its own. To successfully manage your product and maximise value delivery, you should use additional artefacts including the following five:

1. An inspiring vision that describes the ultimate reason for offering the product;
2. A validated product strategy that captures your approach to realise the vision and make the product successful.
3. An outcome-based, goal-oriented product roadmap, which shows how you intend to implement the strategy and states the specific benefits the product should create in the next, say, twelve months;
4. KPIs that measure the value your product creates and help you understand if the strategy is working;
5. A business model that explains how you intend to realise the desired business benefits and in the case of a commercial product, how it is monetised.

Note that none of the five artefacts is part of Scrum. But this does not mean that they cannot or should not be used in combination with the framework. As I mentioned earlier, Scrum is not a product management framework. It therefore offers only limited support for product people.

4 Take Advantage of Product Goals

I like to think of a product goal as the specific outcome that a product should achieve in the next two to three months, for example, to increase conversion, to decrease churn, or to future-proof the product by removing technical debt.[4] Using product goals offers you the following four benefits:

First, they focus and direct the product backlog. Many backlogs I have seen were too long and too detailed. But such a backlog is difficult to prioritise, refine, and update. It makes it hard to successfully deliver a product. Using a product goal addresses this issue: You only add an item to the backlog if it helps you meet the goal. Otherwise, you discard it, at least for now.

Second, product goals provide a continuity beyond the current sprint and help align everyone involved in delivering the product: Everybody should be working on the same product goal at a given point in time.

Third, product goals help you connect the product roadmap and the product backlog, assuming that you use a goal-oriented plan like my GO product roadmap. Choose the next outcome on the roadmap as your product goal and copy it into the product backlog.

Fourth, product goals help you discover the right sprint goals, which, in turn, direct the work of the development team. Simply ask yourself, “What is the next step we have to take to move forward and meet the product goal?”

5 Inspect and Adapt to Maximise Value

If applied correctly, Scrum removes most of the guesswork from delivering a product. Instead of writing down the requirements before any development has taken place and hoping that they are comprehensive and correct, you start with a sketchy product backlog, build a first increment, show it to users, customers, and stakeholders, and evaluate their feedback.

This enables you to quickly try out new ideas and learn which ones create value and which don’t. To put it differently, Scrum’s iterative nature allows you to make data-informed product decisions thereby maximising the chances of delivering a product that does a great job for the users and customers.

To successfully inspect and adapt your product, collect feedback early and often, for instance, by demoing or releasing product increments. Use the data you gather to validate your decisions and generate new ideas. Answering the following four questions with help you with this:

1. Are you developing a product that is usable and beneficial for the users? Does it offer the right user experience (UX) and the right functionality?
2. Can the product be successfully offered? For example, can it be effectively marketed, sold, and serviced?
3. How can you further improve the product to maximise the value it creates, for example, by enhancing, adding, or removing a feature?
4. What changes should you make to the product backlog? Will any of them impact the product roadmap and require an update?

Note that frequently adapting your product requires that it’s easy to modify the code. If the software is brittle and the code quality is poor, changing the product will take longer and be more expensive. It is therefore worthwhile to measure the code quality and minimise technical debt.

6 Fully Leverage the Product Backlog

I find it ironic that the only product management artefact Scrum offers is commonly misapplied. To take full advantage of the product backlog and leverage it to deliver a great product, follow these five tips.

First, use the product backlog for what it’s good at—as a tactical product plan that captures product functionality, for example, in the form of epics and user stories.

Second, use a product goal to direct the product backlog, as I recommended earlier. This will result in a concise and focused backlog that is relatively easy to manage and change.

Third, prioritise the product backlog. I like to use risk, cost-benefit, and dependencies to determine the right order, especially for a backlog that is governed by a product goal.

Fourth, regularly update the backlog by using the data you collect from users, customers, and stakeholders based on the latest product increment. Remove, add, and adjust items. Ensure that the high-priority items are ready to be delivered in the next sprint.

Fifth, involve the development team members in the backlog work. This leverages their expertise, it helps you discover technical risks, and it leads to better, clearer product backlog items.

7 Don’t Get Hung up about the Term Product Owner

As you probably know, the person in charge of the product is called product owner in Scrum. The idea behind the name choice is simple: The person who fulfils the role has to be empowered to make a product decision when no agreement can be reached. Figuratively speaking, they should “own” the product on behalf of the company.

But in my mind, it doesn’t matter if people refer to you as the product owner, product manager, or something else. What does matter is that you have the right decision-making authority, that you are committed to offering a product that benefits its users and the business, and that you show empathy and respect to the people who work with you.

8 Guide the Development Team

A development team in Scrum is more than a bunch of people writing software. It’s a cross-functional, self-managing group that incrementally delivers a usable and valuable product.[5] To help the team do a great job, follow these five tips:

First, involve the team members in the discovery/strategy work in addition to the product backlog refinement. While you might be concerned that this reduces the ability to deliver functionality, including team representatives in the discovery-related work allows them to acquire relevant knowledge about the users and to research new technologies and tools. This leads to better design and implementation decisions and a better product.

Second, use a sprint goal to describe the desired outcome of each sprint. Ensure that the team members agree with the goal and that it moves you closer to your product goal.

Third, allow the team to own the work in the sprint. Let the members freely determine what has to be done and how much work can be done. Additionally, don’t interfere with the team’s self-management. It’s the team’s responsibility to organise their work and reach the sprint goal, not yours.

Fourth, hold the team accountable for meeting the agreed sprint goal. Do not put up with a team that repeatedly over promises and under delivers. Address the issue in the next sprint retrospective and together determine the right improvement measures.

9 Involve the Stakeholders

As the person in charge of the product, you usually need the stakeholders’ support to successfully deliver a product. The following four tips will help you align and guide them:

First, focus on the key stakeholders, the individuals who take an interest in your product and whose help you need to progress and provide it. For a commercial product, they are likely to include a marketer, a sales rep, and a customer service team member. 

Second, engage the individuals early and regularly. The stakeholders should participate in the discovery and strategy work, and they should regularly attend the sprint review meetings. The latter allows them to see how the product is progressing, offer their feedback, and share their ideas.

Third, form a product team. Scrum is a team-based approach. While it promotes a Scrum team, this group does not include any stakeholders. I therefore recommend creating a larger team, which extends the Scrum team and includes the key stakeholders. I call this group the product team.

Fourth, don’t be afraid to say no to the stakeholders and hold them accountable for meeting agreed goals. A common mistake I see product people make is to believe that they have to please the stakeholders. But that’s wrong. Your job is to deliver a successful product and maximise the value it creates—not to make the stakeholders happy.

10 Don’t Do Scrum without an Effective Scrum Master

Having an effective Scrum Master truly is crucial when you want to use Scrum to maximise value delivery. Unfortunately, the role is often not filled. Other times, Scrum Masters are stretched too thinly, or they lack the necessary skills.

If that’s the case for you, then don’t make the mistake of taking on the role. This will make your job even more challenging and stressful. Instead, address the issue. If the role is not filled, then help the decision makers in your company understand that Scrum Masters are not optional.

If you have a Scrum Master, but you are not happy with their work, then share your perspective with them in a constructive, non-judgemental way. Offer your help, when possible and appropriate. If this does not improve the situation, then it might be best to look for another person who can play the role in a more effective way.

Bonus Tip: Practise Sustainable Pace

As the person in charge of the product, you have a demanding job with a range of diverse duties that compete for your time and attention. This makes it easy to work too hard and exhaust yourself. To stay healthy, motivated, and productive, look after yourself and practise sustainable pace. The following four recommendations will help you with this:

First, focus on your job. Don’t take on other responsibilities, at least not permanently, and only attend meetings that require your presence.

Second, delegate and share some of your work. For example, the development team might be happy to carry out some of the backlog refinement work on their own. Additionally, involve other product people and share the work if the product grows and the product management effort gets too much for one person.

Third, don’t neglect important, non-urgent tasks. It can be tempting to skip the continuous discovery and strategy work. But this usually means that you overlook opportunities and threats and therefore generate more work for yourself in the future.

Fourth, take regular breaks and don’t get into the habit of routinely working overtime. Use your lunch breaks and holiday allowance to recharge your batteries. This will enable you to deliver great products while being healthy and well.

Notes

[1] You can think of a product increment as a reusable prototype, as a step towards a new product or a new product version/release.

[2] While I’ve developed a product strategy framework and strategy tools like my product vision board that connects to an agile, Scrum-based process, I am certainly not the only person to recommend complementing agile development practices with strategy and discovery. Shout-out to Ellen Gottesdiener and Gabby Benefield for their work.

[3] For simplicity purposes, I ignore the option to use Scrum to carry out strategy work using discovery sprints. As I explain in my book Strategize, I find that a Kanban-based process is a better choice for this job.

[4] Product goals are a comparatively new addition to Scrum. They were first introduced in the 2020 Scrum Guide.

[5] The 2020 Scrum Guide has replaced the term development team with “developers.” But as you’ve probably noticed, I use the older, more established term in this article.

Listen to this article:

Product Goals Defined

The Scrum Guide released in November 2020 states that “the product goal describes a future state of the product … [It] is the long-term objective for the Scrum team.” It also suggests that “the product goal is in the product backlog. The rest of the product backlog emerges to define ‘what’ will fulfill the product goal.” The product owner is accountable for “developing and explicitly communicating the product goal.” The entire Scrum team is “focused on one … product goal” at a time.

If this definition leaves you scratching your head, don’t worry. Scrum is a simple framework designed to facilitate the development of complex products. It does not intend to prescribe how the practices it offers should be applied. As a consequence, different people have suggested different ways to apply the product goal. Some view it as the product vision, others equate it to the product’s value proposition.

I find, however, that a product goal is best used to describe a specific and measurable benefit or outcome a product should create in the course of the next two to six months. A sample goal might be to acquire users, increase conversion, generate revenue, or reduce technical debt. Such a goal aligns the stakeholders and development teams, and it directs their work.

What’s more, I like to ensure that product goals are connected to the product strategy and its user and business goals. This helps me choose the right product goals and it ensures that meeting a product goal is a step towards creating the desired value for the users and the business, as figure 1 shows.

In figure 1, the vision is the basis for choosing the user and business goals, and the latter create the context for determining the right product goal. At the same token, each product goal acts as the foundation for identifying helpful sprint goals. In other words, the goals are connected and form a cascading set of product-related goals.

Please see my article “Leading Through Shared Goals” and my book How to Lead in Product Management for more information how to effectively use the goals in figure 1, which includes securing the necessary buy-in from the stakeholders and development teams.

Background Story: Readers familiar with the history of Scrum—sometimes lovingly referred to as Scrumtorians—will undoubtedly know that it has contained sprint goals at least since 2002 and a (product) vision since 2004, even though the latter is not mentioned in the Scrum Guide. When I started to work with Scrum in 2004, I could not get my head around the question of how to systematically connect a big, inspiring vision to a tactical, short-term sprint goal. It took me years to come up with the set of goals in figure 1. In hindsight, the set looks disappointingly simple 😉

You can also access the contents of this article on my YouTube Channel:

Sample Goals

To better understand how the goals in figure 1 can be applied, let’s take a look at an example.

In figure 2, I first captured the vision “Help people eat healthily” and then used it to choose the user and business goals “Reduce the risk of developing type-two diabetes; create new revenue source.” In order to determine the right product goal, I asked myself, “What would be a first good step to meet the from the user and business goal?” I consequently chose the product goal “Help the users understand their eating habits and acquire an initial user base.” I then used this goal to determine the right sprint goal. I figured that finding out if users are willing to share personal information when activating the app would be the most important risk to address and hence should be the goal of the first sprint.

Note that I chose to use a compound product goal in figure 2 that has a user part—help the users understand their eating habits and business—and a business one—acquire an initial user base. Both parts are closely connected: In order to acquire a user base, the product must offer tangible value to the users, and a first step to help people eat more healthily is to help them become aware of their current eating habits. You don’t have to work with compound product goals of course, if you prefer to focus your objectives on either the user or the business benefits.

Product Goals and the Product Roadmap

Setting a single product goal is great. But unless you can’t see further than the next few months, I recommend determining the next three to four product goals and capturing them on your product roadmap, as figure 3 below shows.

Figure 3 shows a sample roadmap based on my GO product roadmap template, which contains three product goals. Each goal builds on the previous one thereby nicely progressing the product: The first goal helps the users become aware of their eating habits and creates and initial user base. The second one helps people improve their eating habits and acquires additional users. The third product goal, finally, helps the users improve their overall fitness and generates revenue.

While the Scrum Guide does not mention identifying future product goals and adding them to the product roadmap, I find this practice very helpful: Stakeholders and dev teams usually benefit from understanding how to product is likely to evolve beyond the next two to three months. This helps the individuals create an effective sales and marketing strategy, for example, and to make the right architecture and technology decisions.

Product Goals and the Product Backlog

With a product roadmap in place, I like to select the product goal to be worked on and copy it from the roadmap to the product backlog together with any coarse-grained features that are associated with the goal. This approach is illustrated by figure 4.

The beauty of using a product goal in the backlog is that it focuses the latter, as I describe in my article “The Product Roadmap and the Product Backlog.” This addresses a common issue: Many product backlogs I have seen over the years were too big and too detailed. This made them hard to prioritise and difficult to update, which is bad news as long as your product is young or experiences more than small, incremental changes. In most cases, the product backlogs grew so big because they lacked a measure to decide which items should be added to the backlog and which should not. The product goal is this measure: Only add an item to the product backlog if it helps meet the product goal.

Let’s briefly explore how a product goal might be used on the product backlog. Say I was to start the development of my healthy eating product, I would copy the product goal “Help the users understand their eating habits and acquire an initial user base” into the product backlog together with the features “healthy eating dashboard” and “integration with smart watches and fitness devices.” I’d ask myself which additional features are required to meet the product goal and add these to the backlog. I would the start breaking some of the features into epics and prioritise the product backlog. Finally, I’d refine the high-priority items to be ready to start the first sprint.

As you can tell, I like product goals and find them very helpful, and I would encourage you to try them out if you haven’t used them.

Listen to this article:

Once Upon a Time in Waterfall Land

Before the advent of agile frameworks like Scrum, a product person—the product manager—would typically carry out the market research, compile a market requirements specification, create a business case, put together product roadmap, write a requirements specification, and then hand it off to a project manager. The latter would work with one or more development teams to get the specification implemented.

During the development phase, the product manager would be only loosely involved, typically attending a project steering meeting and possibly issuing change requests. Otherwise, the individual would hope that the requirements were implemented as specified. Only once the product was close to being finished would the product manager return to the project and prepare the release of the product.

This sequential, waterfall-based approach used to work when there was little change and innovation, when product managers could correctly predict what the users needed and describe the detailed product functionality upfront. But it is less suited to create complex digital products.

You can also access the content of this article on my YouTube channel.

The Brave New Agile World

As agile practices have become more widely adopted, the processes used to develop products have significantly changed: Product people and development teams now tend to collaborate much more closely. Dev teams have become cross-functional consisting of UX designers, architects, programmers, testers, and other roles. Products are developed using iterative-incremental processes like Scrum. Requirements are no longer detailed and frozen before development starts but they emerge. An increasing number of organisations have moved away from organising around projects and have started to embrace a product-led approach.

Early user feedback, frequent solution validation: We now have the ability to collect early and frequent user and customer feedback, which helps us validate our ideas and update our plans accordingly. This has increased the chances of creating a product with the right UX and the right features.

Reduced time-to-market: We can now release new products and features more quickly. This is enabled by a closer, ongoing collaboration with cross-functional development teams, shifting from written documentation to face-to-face conversations, and using techniques such as user stories that reduce overhead—when applied correctly.

Better product quality and improved adaptability: The quality of our products has improved through the application of agile development practices like emergent design, test-driven development, and continuous integration. This has allowed us to adapt the product more quickly and to respond to user feedback more easily.

Better requirements: As product people, we are no longer solely responsible for coming up with the correct requirements. Instead, the dev team members actively participate in the product backlog refinement work and help us identify the necessary changes and capture new product backlog items. This leverages the team members’ creativity and expertise, creates a shared understanding, fosters collective ownership, improves the quality of the requirements, and ultimately results in better products.

Transparent development progress: We can see the development progress more clearly and make corrections early if required: The progress is now based on working software rather than a detailed, Gantt chart-based project plan. This mitigates the risk of discovering late that the product cannot be shipped on time or that some features were implemented incorrectly.

Improved alignment: Stakeholders and development teams are now better aligned through the use of regular collaborative workshops like sprint reviews. This creates a shared understanding and leads to greater commitment: Asking people about their perspectives and involving them in the process of making product decisions increases the likelihood that the individuals will support the decisions.

Motivated productive teams: Last but not least, self-organising development teams tend to be more motivated and productive compared to traditional ones, as they are able to determine themselves how much work can be done in a given period, decide who carries out a specific piece of work, and agree on how the team members collaborate.

Old and New Product Management Challenges

While agile methods have given us plenty of benefits, a number of product management challenges still persist. These were not caused by agile practices, as far as I can tell. Agile has made them more visible, though, and it has exacerbated some of them. Let’s look at the key challenges that remain.

Lack of empowerment: When coining the Scrum terms, Ken Schwaber and Jeff Sutherland chose the term product owner instead of product manager in order to emphasise the level of authority and empowerment a product person requires—especially in an agile context where collaboration is valued, and stakeholders and dev teams regularly contribute to product decisions.

Unfortunately, a lack of empowerment is still a common issue: Product people often don’t have the necessary authority to make strategic product decision, shape the strategy, and own the roadmap. Consequently, they are in danger of playing a tactical product role and being product backlog managers and user story writers rather than owning the product in its entirety and being able to maximise the value it creates.

Confusion about roles and responsibilities: Even 20 years after the Manifesto for Agile Software Development was conceived, agile roles like product owner and Scrum Master are not always clearly understood, let alone effectively applied. As indicated above, product owners are sometimes mistaken for product backlog managers and stakeholder pleasers instead of the individuals who are in charge of a product and whose decisions the entire organisation must respect, as the Scrum Guide puts it.

Lack of direct interaction with users and customers: Customer collaboration is one of the four values in the agile manifesto. Nevertheless, it’s not uncommon for me to meet product people who don’t have direct access to users and customers. Instead, they solely rely on quantitative data and feedback from sales, which makes it hard to empathise with the users and customers and to fully understand their needs. This, in turn, reduces the chances of offering a product that does a great job for its target audience and generates the desired business benefits.

Product strategy is poorly practiced: The most beautiful user stories are useless if it’s not clear who the users are and why they would want to use the product. Acquiring this information requires focused product strategy work. Unfortunately, product strategy aren’t always effectively practiced. This is not helped by the fact that agile approaches like Scrum do not offer any tools and techniques to help product owners understand if a product should be developed. Fortunately, a number of tools and techniques have emerged in recent years that help product people with their product strategy work including my product vision board and GO product roadmap.

Lack of sustainable pace: “The sponsors, developers, and users should be able to maintain a constant pace indefinitely,” states the Manifesto for Agile Software Development. Ironically, working at a healthy, sustainable pace can be particularly challenging in an agile context: Product people have to regularly interact with development teams in order to update the product backlog, agree on sprint goals, answer questions, and provide feedback on product increments in addition to all the other product management duties. Being overworked, however, has a negative impact on our productivity and mental health. Luckily, there are a number of practical measures you can take to achieve sustainable pace. These include not covering other people jobs on a continued basis—like acting as a stand-in Scrum Master—and having the courage to decline stakeholder requests. Please see my article “Sustainable Pace in Product Management” for more guidance.

Looking into the Crystal Ball

So where do we go from here? How will product management change over the next 20 years, and which role will agile methods play—if any?

Without having a crystal ball at my disposal, I believe that the future of product management will be shaped by our ability to address the product management challenges mentioned above. I sincerely hope that in 20 years from now, empowerment will no longer be a significant issue, product roles will be better understood and more effectively applied, and product strategy will always be practiced by anybody who manages or owns a product. I also believe that agile methods will continue to enrich product management, alongside other influences that have emerged in the last few years including Lean Startup and business modelling.

While there is still plenty of work to be done, I am optimistic about the future of product management and agile.

Listen to this article:

Enter the Cycle

Traditionally, strategy and execution are often viewed as separate, sequential pieces of work that are carried out by different people. For example, a product manager might determine the product strategy and one or more development teams might be tasked with executing it. But as long as innovation, change, and risk are present, this approach is ineffective. Instead, strategy and execution have to be closely connected: The former should not only guide execution, but execution should inform strategy changes and help adapt the strategy.

Based on this insight, I have come up with the product strategy cycle shown in the picture below. It’s a model of an iterative process that systematically links the product strategy with the product roadmap, the product backlog, the development work, and the key performance indicators (KPIs).

In the picture above, the process starts at the top of the cycle by creating a new strategy, either for a brand-new product or an existing one. In the latter case, a new strategy might be required to extend the product’s life cycle, for example, by addressing a new market or market segment. An effective product strategy should capture the product’s target group, value proposition, standout features, and business goals.

Before you proceed further, you should validate your new strategy and address key risks and assumptions in order to maximise the chances of achieving product success. For example, the market segment you have chosen might be too big and heterogenous, the value proposition might not be compelling enough, or the business goals might not be feasible. Identifying and addressing the key risks in the product strategy is best done iteratively, as I explain in more detail in my book Strategize. I have therefore placed a small cycle next to “Product Strategy” in the picture above.

Once you’ve addressed the key risks and you are confident that you have chosen the right needs, market, standout features, and business goals, you can take the next step and derive a product roadmap from the strategy. I view the roadmap as a product plan that describes how you intend to implement the strategy and which specific benefits or outcomes the product should provide over the next, say, 12 months, based on the needs and business goals stated in the product strategy. I call these outcomes product goals. Sample product goals are acquiring new users, increasing engagement, removing technical debt to future-proof the product, and generating revenue.

With an actionable product roadmap in place, move on and stock your product backlog. To do so, choose the next product goal stated on the product roadmap, determine the features and functionality required to meet it, and capture them in the backlog. Then create just enough ready product backlog items to be able to start the upcoming sprint and develop the actual product. As an iterative process is usually best suited to create a new product or a major product update, I’ve added another little cycle between “Product Backlog” and “Product” in the picture above.

After development has started, measure the development progress, for instance, by using a release burndown chart. When an initial or new version of the product has been released, use the KPIs to measure the product performance. These should include the metrics required to determine if the product goal chosen has been met and additional indicators that help you assess how your product is doing and if the strategy is working. Examples of the latter are engagement, retention, product quality, team motivation, and in the case of a revenue-generating product, revenue and cost.

Use the KPIs and the development progress data to review the product strategy and the product roadmap, and change them as appropriate. This might involve making smaller, incremental adjustments. But it might also require you to pivot, to significantly change the strategy in order to make the product successful. Take YouTube as a well-known example. The product pivoted from a dating website to a video-sharing platform.

You have now completed the cycle and started another one.

Involve the Right People

Systematically connecting strategy and execution is a key factor to establish an effective product strategy practice. But it is not enough. The best product strategy is useless if the stakeholders and development team(s) do not buy into it and are not prepared to implement the decisions that it captures.

To maximise the chances that people understand and support the strategic product decisions, I recommend that you involve the key stakeholders and development team representatives in creating and validating the product strategy, developing the product roadmap, tracking the KPIs and development progress, and updating the plans. Inviting people to contribute to strategic decisions makes it more likely that they understand and support them. What’s more, this allows you to leverage their expertise, which makes it more likely that you will make the right decisions. If you work on a larger product and in a scaled environment, include the product people who work with you, for example, the feature owners.

A great way to engage the key stakeholders and development team members is to run a collaborative workshop, be it online or in the office. Ask your Scrum Master or another experienced facilitator to help prepare the workshop and facilitate the session. This includes establishing ground rules, selecting a helpful decision rule like consent, and ensuring that everybody is heard, and nobody dominates. (You can find more advice on collaborative decision-making in my book How to Lead in Product Management.)

Involving the stakeholder and development team members in the decision-making process puts collaboration at the centre of the strategy cycle, as the picture below shows.

Final Thoughts

“All models are wrong, but some are useful,” as George Box once observed. Every model is an abstraction of reality. It therefore simplifies or ignores certain aspects and leaves out some details. This is also true for the process that I have described in this article. In reality, things are a little bit more complicated.

There are two aspects I’d like to draw your attention to: First, you should measure the development progress, as soon as the dev team has started to transform the product backlog items into a product increment. Once you have enough data to see a clear trend—which tends to be the case after two to three sprints—check if the product goal can be met on time and on budget. If that is not the case, then you might have to adjust the product roadmap, which might even trigger an adjustment of the product strategy. Similarly, if your product backlog experiences significant changes, as you find out, for instance, that a key feature is not required or has to be replaced, you should consider the impact on the product roadmap and update it as soon as possible.

Second, you should not forget to engage in continuous strategizing, which includes frequently monitoring new trends and the competition. As I have suggested before, spend at least half a day per week carrying out continuous discovery and strategy work including reviewing relevant trends and keeping an eye on the competition. This ensures that you do not miss any threats and opportunities and that you can respond to changes early rather than reacting to them with your back against the wall.

What is Product Strategizing?

Product strategizing describes the activities required to determine if and why a product should be developed and offered. This increases the chances of creating a product that users actually want and need and achieving product success, and it involves answering the following questions:

• What is the specific value the product should create for the users and customers? What problem should it solve, or which benefit should it create?
• Which market and market segment should the product address? Who are the users and who are the customers?
• What makes the product stand out? How will it differ from competing offerings?
• What are its business goals? How will it benefit the company? For example, generate revenue or meet a profit margin, reduce cost, or develop the brand?
• What business model will it use in order to achieve the business goals, including revenue sources, cost factors, and channels?
• Will the product make a positive impact on people’s lives, the wider society, and the planet, or will it at least not cause any harm?
• How might people use the product? What are the major touch points? What kind of user experience (UX) should the product give rise to?
• How can the product be built? What architecture patterns and technologies may be used?

In order to answer the questions above, you may want to use techniques such as direct observation, user interviews, prototyping, creating a strategy canvas or E-R-R-C grid, and you may capture some of them using a tool like my Product Vision Board. Whatever you do, I suggest that you follow Steve Blank’s advice and “get out of the building”. Meeting users and customers, at least in the form of a video call, not only helps you validate your assumptions and develop new ideas. It also allows you to empathise with the individuals and to better understand their perspectives and needs.

I find it helpful to distinguish two types of product strategizing: timeboxed and continuous discovery. Let’s look at timeboxed strategizing first.

Timeboxed Product Strategizing

Whenever you create a brand-new product or when you make bigger changes to an existing one, like taking it to a new market, you will benefit from using a dedicated, timeboxed product strategy period. This results in an innovation process like the one shown in the picture below.

In the picture above, the product strategy work precedes product development. The former focuses on understanding if and why a product should be created or updated. The latter largely determines how the product should be developed. This includes discovering the right UX design and functionality and making the right technical decisions.

Note that I have purposefully drawn discovery and development as overlapping, as I find it helpful to address major UX and technical risks as part of the strategizing work—without making the mistake of using big design upfront (BDU). Addressing these risks ensures that the development team has the right knowledge to hit the ground running when starting development. Consequently, the key deliverables include the following:

• Validated product strategy and business model,
• Actionable product roadmap that implements the strategy,
• Valid business model,
• Initial product backlog that captures the necessary product details,
• A high-level UX design concept and coarse-grained software architecture supplemented by throwaway prototypes (spikes).

As it’s notoriously difficult to correctly forecast how much time a bigger piece of strategy work will require, I recommend timeboxing it. To do so, consider the amount of innovation and risk present and allocate an appropriate timebox. If you were to develop a brand-new product for a new market with new technologies, for instance, then you would face more risks compared to taking an existing product to a new market. Consequently, the former will require more time than the latter. You might want to allocate, say, two months for the first initiative, but only two weeks for the latter, assuming that you already serve the new target market. Additionally, I recommend running weekly review sessions to understand the progress of the discovery work and adapt it if necessary.

To carry out the strategizing work, bring together the right people, product person, development team representative, key stakeholders, and Scrum Master or agile coach, as shown in the picture below.

As the person in charge of the product, you should lead the strategizing and development effort. Here’s why: You can’t be responsible for maximising the value a product creates if you don’t actively participate in, guide the discovery work, and shape strategic product decisions.

Development team representatives—ideally a UX designer, one or two developers, and a tester—should also engage in the discovery activities. This leverages the individuals’ knowledge and creativity; it surfaces feasibility issues and technical risks; and it allows the team members acquire knowledge about the market and users and understand why the product is being created or updated. The latter will enable the development team to make the right design and technical decisions and own the solution. Do make sure that the individuals continue to work on the team in development and help build the product. Otherwise, you are likely to lose precious knowledge and time.

Inviting the key stakeholders to participate in the product strategy work ensures that their ideas and concerns are taken into account at an early stage; it takes advantage of their expertise; and it maximises the chances that they will support the resulting strategic product decisions: When people are given the opportunity to contribute to a decision, they are more likely to understand and buy into it.

The Scrum Master or agile coach, finally, should facilitate the discovery process and the meetings in order to ensure that everybody is heard, and nobody dominates. This may include suggesting applying a Kanban-based process to visualise and manage the discovery and strategy work, as I recommend in my book Strategize.

Continuous Strategizing

As helpful as timeboxed product strategizing is, it is not enough. Here is why: When you create a brand-new product, you typically aim to launch a minimum viable product (MVP), a good enough offering that addresses the early market. To achieve product-market fit and make the product successful, more discovery work is required: You now need to figure out how to adapt your product to serve the needs of the mainstream market. But even once you’ve entered the growth stage, you can’t afford to neglect the product strategy. The world doesn’t stand still: Markets and technologies change, competitors improve their products, and new market entrants may appear.

Product management is therefore like riding a bike: When I am on my bike—which is one of my favourite pastime activities—I have to turn the cranks, change gears, steer the bike, and so on. But if I forget to look ahead, I’ll sooner or later get lost or even crash. The same is true for your product: If you are completely immersed in execution and forget about discovery, you’re likely to miss an opportunity or threat and experience difficulties further down the line.

It is therefore important that you carry out continuous strategizing. This includes the following activities:

• Review the product performance using the appropriate key performance indicators. Analyse the data collected to understand how your product is doing. Do the metrics show a positive, flat, or negative trend? What conclusions can you draw from the analysis? What measures would help you achieve the desired product performance?
• Look for opportunities. Are there any new technology, regulatory, or social trends that you should be aware of? Do they offer an opportunity to innovate, add, remove, or enhance product features, or even create a brand-new product? Talking to users, attending trade shows and conferences, and participating in online communities can help you spot new trends. Giving the dev team time to investigate new technologies will allow you to take advantage of opportunities and improve your product.
• Keep an eye on the competition. Are your competitors launching new products or features? Are there any new market entrants? Should you respond to any of these changes? If so, which actions are appropriate? Job postings can help you guess your competitors’ plans. Reviewing their products will tell you if your product is still sufficiently differentiated.
• Follow the developments at your own company: Are there any changes to the business strategy? And if so, what are the consequences for your product?

To help you answer the questions above and carry out the related work, I recommend the following two measures:

First, block at least one hour per day in your calendar to carry out the necessary product strategy work. This helps you avoid nasty surprises, such as a competitor leapfrogging you by offering a new killer feature, and it makes it more likely that you recognise early warning signs like declining sign-up rates, increasing churn, or a growing number of support calls. This allows you to be responsive and take action early.

Second, regularly hold collaborative strategy reviews, once per quarter, as a rule of thumb. Assess the product strategy and product roadmap together with development team representatives and key stakeholders. These are ideally the same people who participated in the timeboxed discovery work and who helped you create the current product strategy and roadmap. As mentioned before, involving dev team members and stakeholders leverages their collective creativity and knowledge, creates alignment, and mitigates the risk that the individuals don’t support necessary strategy changes.

A Few Thoughts on Product Strategy in a Scaled Environment

If you manage a larger product and you work in a scaled environment, don’t forget to involve the other people who look after the product, for example, feature and component owners or SAFe product owners, in both timeboxed and continuous strategizing.

In addition to the collaboration benefits already mentioned, this makes it more likely that strategic decisions will be translated into tactical ones, and it ensures that tactical insights—like the knowledge gained from analysing user feedback on specific features—inform the strategic decisions.

Listen to this article:

What are Feature and Component Teams?

A feature team is a development team that implements end-user functionality end-to-end. Contrast this with a component team. Such a team owns an architecture building block, for example, a layer, a subsystem, or a collection of components or services, as figure 1 illustrates.

Figure 1 depicts a simple software architecture that consists of three layers: user interface, business logic, and data. Say that I want to develop an app that helps people eat healthily. A feature team might then develop the capability that allows users to see their eating trend, for instance. It would implement the feature as a vertical slice, from the user interface down to the data layer. A component team, however, might develop the business logic that calculates recommended calorie intake. The team would not touch any of the other layers but exclusively focus on the business logic.

Why Does this Matter to Product People?

When your product starts to attract more users, you typically require more development teams to sustain the growth, enhance features, and add new ones. This presents you with a choice: You can organise the teams primarily around features or architecture building blocks. This choice matters: It will affect your ability to progress your product and achieve its strategic goals, as I explain in more detail below.

Feature and component teams both come with benefits and drawbacks. The former have a strong end-user focus: They work on functionality that creates value for the end users. Feature teams can also consume items directly from the product backlog and turn them into working software. Additionally, they are loosely coupled and not dependent on the work of other feature teams. This has two benefits: First, it allows you to quickly test an idea and release a feature fake or early version of a feature, gather user feedback, and adapt it. Second, if one feature team fails to deliver, then you can usually still use the work of the other teams. But using feature teams can introduce user experience and architecture inconsistencies and it can lead to code duplication. In the worst case, each team creates its own user experience and user interface design, its own business logic, and its own data layer, to stay with the architecture example shown in figure 1.

Component teams avoid these drawbacks. As they are organised around architecture building blocks, they enforce architecture consistency. Additionally, it can be easier to staff component teams compared to feature teams. In figure 1, every feature team would need someone with the appropriate user interface design skills, for instance. On the downside, component teams often cannot consume items directly from the product backlog. The teams that own the business logic and data layer in figure 1 need technical requirements that describe the interfaces that should be created or enhanced. Translating end-user requirements into technical ones creates overhead and slows down development. What’s more, as component teams tend to build software for other development teams, they can lose sight of the end users and sub-optimise their building blocks: I have seen component teams who were more concerned about the performance of their components than the end-user experience.

When are Feature Teams Preferable and When are Component Teams Better?

I recommend that you prefer feature teams over component teams as long as your product experiences bigger changes. This is typically the case for brand-new products, products in the introduction stage, products that rapidly grow, and products whose life cycle is being extended, for example, by taking them to a new market or adding new features. But once your product is stable, once it has entered the maturity stage (and you don’t intend to extend its life cycle), then component teams tend to be a better choice, as figure 2 shows.

Features teams allow you to move fast, add new functionality, respond to user feedback, and adapt your product. This makes them better suited for coping with innovation, uncertainty, and change—challenges that are present at the early life cycle stages and a life cycle extension.

Component teams help you reduce cost and increase profitability by maximising reuse and ensuring architecture integrity. This is desirable for mature and declining products, where you typically focus on incremental enhancements and bug fixes, and cost reduction.

Consequently, it can be beneficial to change the team setup after a product has entered the maturity stage. But this should always be done with the agreement of the development teams: Telling teams that they will be disbanded and newly assembled conflicts with the idea of having empowered agile development teams.

What about a Mix and Match?

You can, of course, combine feature and component teams. But the advice above still holds true: Be clear on the team setup that benefits your product most. For instance, when managing a young product, you might find it beneficial to have one component team that looks after the data layer. But if that’s what you decide to do, make sure that there is a good reason for using a component team, and keep the number of component teams to a minimum at this stage. Similarly, when you need to make a bigger change to a mature product like a substantial feature enhancement, you might want to use a feature team to get the work done.

Don’t forget, though, that teams need time to gel. Team members have to learn to trust each other and build connections in order to be able to effectively work together. Frequently changing the team setup is therefore undesirable.

Notes

Feature teams are also used in the agile scaling framework LeSS. The team topologies framework offers an alternative approach to organise teams. You can view feature teams, as described in this article, as a type of stream-aligned teams and component team as complicated subsystem teams.

1 Involve the Right People

A small group of qualified individuals who have the right skills and motivation can be more productive than many individuals who lack the necessary expertise and act out of obligation. This is true for product people and development team members alike in my experience. Therefore, make an effort to involve the right individuals. This will allow you to move faster, stay small for longer, and be more adaptive.

While this probably sounds like common sense, I’ve seen more than one organisation trying to get more done by throwing people at a product. One company I worked with, for example, assigned developers who had worked on enterprise systems using an ancient programming language to develop a brand-new, embedded product with the latest technologies. No wonder that the individuals struggled and the product suffered.

Your Scrum Master should be able to help you find the right people and address any impediments that might prevent you from doing so—for example, being assigned individuals without considering their skills and motivation.

2 Don’t Scale Prematurely

I once worked on a new product development effort where more than one hundred developers in three locations had been allocated right from the start of the project. While initially, there wasn’t enough work to keep so many people busy, the development teams didn’t want to twiddle their thumbs and started writing software. This led to a bloated, over-complicated code base and a product that was difficult to adapt and expensive to maintain.

Rather than scaling prematurely, stay as small as you possibly can until you are getting close to reaching product-market fit. This allows you to quickly respond to market feedback, experiment with new ideas, and make any architecture and technology changes that may be required in order to move into the growth stage.

3 Build an MVP

Another great way to reduce the need to scale is launching a minimum viable product (MVP). Such a product typically requires less time and fewer people to develop than a more ambitious, feature-rich one. What’s more, it can be easier adapted to the market response in order to achieve product-market fit.

How minimal your product can be depends on its market. For example, in the case of the original iPhone, Apple created a new market and could therefore offer a comparatively minimalistic product. Contrast this with the Apple Watch, which entered an existing market and directly competed with established offerings from companies like Samsung, Garmin, and Fitbit.

4 Help the Development Team Become Self-sufficient

As your product grows, your workload usually increases too: Addressing a growing number of users requires more effort to understand their often heterogeneous needs and decide how to best address them. If you have a development team that still needs to be spoon-fed with detailed requirements at this stage, then your workload is likely to become overwhelming.

To mitigate this risk, help the development team learn about the users and understand their needs as early as possible, for instance, by involving team members in user research (as part of the product discovery work) and exposing them to direct user feedback on early product increments. This will allow the team members to own the solution and make the right UX and technology decisions, increase people’s motivation, lay the foundations for adding more teams, and free you from having to create detail-rich user stories and still answer lots of questions during the sprint.

5 Grow Organically

Back in 1968, Melvin Conway observed “that there is a very close relationship between the structure of a system and the structure of the organization which designed it.” This means that if you start with, say, three development teams, the software architecture of your product will probably consist of three major subsystems—no matter if this architecture supports the desired user experience and features.

To avoid this risk, start with one product person in charge of the product, one development team, and one Scrum Master. Once you’ve validated key UX and technology risks, scale by asking the team to split up. Then add more people to the newly formed teams. This approach is also called growing organically, as it mimics cell division in living beings.

In addition to escaping Conway’s Law stated above, growing organically offers two more benefits: It evenly spreads the effort of bringing the new people up to speed instead of having one unproductive development team with all the newbies, and it allows you to measure the impact of adding more people on productivity and infrastructure.

The latter might seem rather dull, but I once worked with an organisation that moved up from three to eight development teams in one go in order to accelerate development. Unfortunately, nobody had anticipated that the infrastructure was not able to cope with the increased network traffic caused by the new teams. Consequently, checking-in and checking-out code suddenly took minutes instead of seconds, which meant that the development speed was significantly reduced until the required upgrade work was finally carried out.

6 Employ Feature Owners and Feature Teams

As you add more people to the development effort, consider working with feature teams—teams that implement functionality end-to-end—instead of component teams who look after an architecture building block like the front end or persistence layer. Feature teams have fewer inter-team dependencies compared to component teams and reduce the risk of sub-optimisation, optimising individual architecture building blocks at the cost of the overall product performance. They do require, however, that shared standards are in place to avoid undesirable variations and code duplication: You typically don’t want that every feature team uses its own UI design flavour and writes code that’s already been developed.

As you add feature teams to the development effort—hopefully by growing organically—you also have to consider the impact on your workload. My experience suggests that a single product person is usually not able to work with more than three agile development teams. You will therefore have to consider involving additional product people who can own features and guide the feature teams. I call these individuals Feature Owners. The image below shows how the role can be applied. For more information, please refer to my article “Scaling the Product Owner Role”.

7 Start with One Site and Distribute Work in a Stepwise Fashion (If Necessary)

While it can be hard to bring the right people together, few things in software development are more counterproductive than starting a new product development effort with a dispersed team—a team whose members work in different places, for example, London, Boston, and Bangalore.

As a rule of thumb, the more uncertainty, change, and innovation are present, the more important it is that everyone involved in the development effort is co-located, including the person in charge of the product. This allows you to build rapport, establish an effective collaboration, and agree on shared standards, for example, how to collaboratively refine product backlog items and have effective sprint reviews.

Therefore, start a new product development effort with one team at one site. Once you’ve addressed the key UX and technology risks, consider spreading the work to other sites in a stepwise fashion if that’s required. This allows you to find out how you have to evolve your practices to succeed with the distributed setup, including collaborative product strategy review and product backlog refinement sessions held via videoconferences.

8 Consider Unbundling Features and Creating Product Variants

Growth is a funny thing. While it’s is a reason to celebrate—the product has finally entered the growth stage and become successful—we now have to cope with an increasingly large and heterogenous target group, more diverse needs, more features, and more development teams. But it doesn’t have to be this way.

Remember when Facebook unbundled Messenger in 2014 and launched it as a standalone app? Unbundling is a great technique to avoid that a successful product becomes bigger and bigger, more and more heterogeneous, and requires an ever-increasing amount of people to manage and develop it. Instead, you create a new, specialised product with its own dedicated product person and development team.

Product variants do a similar job: But rather than spinning off one or more features, you create a version that is tailored to a specific target group. Take, for instance, Microsoft’s diagramming tool, Visio, which the company offers the variants Visio Standard and Visio Professional. Each variant can be developed by a separate team and have its own product person who looks after it.

9 Take Advantage of a Platform

A platform bundles shared assets, for example, shared front end or back end components or common services like persistence, logging, and security, and it standardises the way they are used. Using a platform offers two benefits in a scaling context: First, it encourages reuse and avoids the need that each team develops their own, say, logging service. Secondly, it creates and enforces standards across different features and teams, such as a common user interface design.

When creating a platform, you have two options: You can either employ collective ownership and ask the different feature teams to jointly look after and advance the platform. Alternatively, you can manage the platform as a product in its own right with a dedicated platform owner and team. (Note that a platform owner usually requires in-depth technical skills, as the individual is usually required to talk to the feature teams about new interfaces and changes to existing ones.)

My recommendation is to start with the collective ownership. This maximises the chances that the platform does a great job at supporting the end-user facing functionality and it minimises the risk of building an ambitious platform that is difficult to use and integrate with. If and when the platform has grown to big to be collectively maintained and advanced, consider employing a dedicated product person and development team.

10 Never Scale Late in the Game

Scaling successfully requires careful forethought and preparation. It should never be an emergency measure to save a development effort that is in trouble, as “adding people to a late development effort makes it later” (Brook’s Law).

Nevertheless, I have worked with more than one organisation that thought this law would not apply to it and added more people in order to accelerate a project that was in danger of missing its target date, only to find out that this caused additional problems and delayed the project even further. Therefore, consider alternative options to save a late project like partially providing or removing features and postponing the release date. Scaling should not be an emergency measure.