Tag Archives: learning

AgileStrategyCreationTipsFeaturedImage

1 Start with What You Know Now

Traditionally, a product strategy is the result of months of market research and business analysis work. It is intended to be factual, reliable, and ready to be implemented. But in an agile, dynamic environment a product strategy is best created differently: Start with your idea, state the vision behind it, and capture your initial strategy. Then identify the biggest risk or the crucial leap-of-faith assumption, address it, and change and improve your strategy. Repeat this process until you are confident that your product strategy is valid.

StrategyCreationApproaches

This iterative approach, pioneered by Lean Startup, provides several advantages: First, it helps you develop a strategy built on empirical evidence rather than on intuition, authority, or influence. Second, it enforces fast failure and minimises the risk of following the wrong strategy and launching a product that bombs. Third, it avoids carrying out too much and too little market research; it helps you do just enough research to acquire the knowledge you really need.

2 Focus on what Matters Most

The term product strategy means different things to different people, and strategies come in different shapes and sizes. While that’s perfectly fine, an initial product strategy that forms the basis for subsequent correction and refinement cycles should focus on what matters most: the market, the value proposition, the product’s unique selling points, and the business goals. This is where my Vision Board comes in. I have designed it as the simplest thing that could possibly work to capture the vision and the product strategy. You can download it from romanpichler.com/tools/vision-board for free.

VisionBoardTemplate

For an introduction to the Vision Board, please see my post “The Product Vision Board”.


3 Create the Product Strategy Collaboratively

A great way to create your product strategy is to employ a collaborative workshop. Invite the key people required to develop, market, sell and service your product and the senior management sponsor. Such a workshop generates early buy-in, creates shared ownership, and leverages the collective knowledge and creativity of the group. Selling an existing vision and product strategy can be challenging. Co-creation is often the better option.

VisioningWorkshop

Your initial Vision Board has to be good enough to create a shared understanding of your vision and initial strategy and to identify the biggest risk so you can start re-working your board. But don’t spend too much time on it and don’t try to make it perfect. Your board will change as you correct, improve and refine it.


4 Let your Vision Guide you

The product vision is the very reason for creating your product: It describes your overarching goal. The vision also forms the basis of your product strategy as the path to reach your overall goal. As the vision is so important, you should capture it before you describe your strategy.

VisionFirst

Here are four tips to help you capture your vision:

  • Your vision should not restate your product idea. It should rather go beyond it. For instance, the idea for this post is to write about creating an agile product strategy, but my vision is to help you develop awesome and successful products.
  • Choose a broad vision, a vision that engages people and that enables you to pivot – to change the strategy while staying true to your vision.
  • Make your vision statement concise; capture it in one or two sentences; and ensure that it is clear and easy to understand.
  • Try to come up with a motivating and inspiring vision that helps unite everyone working on the product. Choosing an altruistic vision, a vision that focuses on the benefits created for others, can help you with this.

You can find more information on formulating a compelling product vision in my post 8 Tips for Creating A Powerful Product Vision.


5 Put the Users First

Once you have captured your vision, work on your strategy by filling in the lower sections of the Vision Board from left to right. Start with the “Target Group”, the people who should use and buy your product rather than thinking about the cool, amazing product features or the smart business model that will monetise the product. While both aspects are important, capturing the users and customers and their needs forms the basis for making the right product and business model decisions.

ClearTargetGroup

While it’s tempting to think of all the people who could possibly benefit from your product, it is more helpful to choose a clear-cut and narrow target group instead. Describe the users and customers as clearly as you can and state the relevant demographic characteristics. If there are several segments that your product could serve then choose the most promising one.

Working with a focused target group makes it easier to test your assumptions, to select the right test group and test method, and to analyse the resulting feedback and data. If it turns out that you have picked the wrong group or made the segment is too small then simply pivot to a new or bigger one. A large or heterogeneous target group is usually difficult to test. What’s more, it leads to many diverse needs, which make it difficult to determine a clear and convincing value proposition and therefore to market and sell the product.


6 Clearly State the Main Problem or Benefit

Once you have captured your target users and customers, describe their needs. Consider why they would purchase and use your product. What problem will your product solve, what pain or discomfort will it remove, what tangible benefit will it create?

StateMainProblem

If you identify several needs, then determine the main problem or the main benefit, for instance, by putting it at the top of the section. This helps you test your ideas and create a convincing value proposition. I find that if I am not able to clearly describe the main problem or benefit, I don’t really understand why people would want to use and to buy a product.


7 Describe the Essence of your Product

Once you have captured the needs, use the “Product” section to describe your actual product idea. State the three to five key features of your product, those features that make the product desirable and that set it apart from its competitors. When capturing the features consider not only product functionality but also nonfunctional qualities such as performance and interoperability, and the visual design.

CaptureTheKeyFeatures

Don’t make the mistake of turning this section into a product backlog. The point is not to describe the product comprehensively or in a great amount of detail but to identify those features that really matter to the target group.


8 State your Business Goals and Key Business Model Elements

Use the “Value” section to state your business goals such as creating a new revenue stream, entering a new market, meeting a profitability goal, reducing cost, developing the brand, or selling another product. Make explicit why it is worthwhile for your company to invest in the product. Prioritise the business goals and state them in the order of their importance. This will guide your efforts and help you choose the right business model.

StateBusinessGoals

Once you have captured the business goals, state the key elements of your business model including the main revenue sources and cost factors. This is particularly important when you work with a new or significantly changed business model.


9 Extend your Board

The Vision Board’s simplicity is one of its assets, but it can sometimes become restricting: The Product and the Value sections can get crowded as the board does not separately capture the competitors, the partners, the channels, the revenue sources, the cost factors, and other business model elements. Luckily there is a simple solution: Extend your board and add further sections, for instance, “Competitors”, “Channels”, “Revenue Streams”, and “Cost Factors”, or download an extended version from my website.

ExtendingTheVisionBoard

But before using an extended Vision Board make sure that you understand who your customers and users are and why they would buy and use the product. There is no point in worrying about the marketing and the sales channels or the technologies if you are not confident that you have identified a problem that’s worthwhile addressing. Additionally, a more complex board usually contains more risks and assumptions. This makes it harder to identify the biggest risk and leap-of-faith assumption.


10 Put it to the Test

Capturing your vision and initial product strategy on the Vision Board is great. But it’s only the beginning of a journey in search of a valid strategy, as your initial board is likely to be wrong. After all, you have based the board on what you know now rather than extensive market research work.

You should therefore review your initial Vision Board carefully, identify its critical risks or leap-of-faith assumptions, and select the most crucial risk or assumption. Determine the right test group, for instance, selected target users, and the right test method such as problem interviews. Carry out the test, analyse the feedback or data collected, and change your Vision Board with the newly gained knowledge as the picture below shows.

TestingTheProductStrategy

If you find that the key risks and assumptions hard to identify then your board may be too vague. If that’s the case then narrow down the target group, select the main problem or benefit, reduce the key features to no more than five, identify the main business benefit, and remove everything else.

Your board may significantly change as you iterate over your strategy, and you may have to pivot, to choose a different strategy to make your vision come true. If your Vision Board does not change at all then you should stop and reflect: Are you addressing the right risks in the right way and are you analysing the feedback and data effectively?


Learn More

You can learn more about creating an agile product strategy and working with the Vision Board by attending my Agile Product Strategy and Roadmap training course. Please contact me if you want me to teach the course onsite or to deliver it as a webinar/virtual training course.

RertoFeaturedImage

The Retrospective in a Nutshell

The sprint retrospective is an opportunity to pause for a short while and reflect on what happened in the sprint. This allows the attendees to improve their collaboration and their work practices to get even better at creating a great product.

The meeting takes place right at the end of the sprint after the sprint review meeting. Its outcome should be actionable improvement measures. These can range from making a firm commitment to start and end future meetings on time to bigger process changes. The retrospective is not a finger-pointing exercise. As Mahatma Gandhi famously said: “Be the change you want to see in the world.”


Take Part

As the product owner, you are a member of the Scrum team, which also includes the development team and the ScrumMaster. While you are in charge of the product, you rely on the collaboration of the other Scrum team members to create a successful software product. If you don’t attend the retrospective as the product owner, you waste the opportunity to strengthen the relationship and to improve the collaboration with them.

TheScrumTeam

But there is more to: Taking part in the sprint retrospective allows you to understand why the team requires some time in the next sprint to carry out improvements such as refactoring the build script, or investigating a new test tool; and maybe more importantly, it helps you improve your own work.

Say that some of the user stories the team had worked on did not get finished in the sprint. At first sight this looks like the development team’s fault. But analysing the issue may well reveal that the size of the stories and the quality of the acceptance criteria contributed to the problem. As you are responsible for ensuring that the product backlog is ready, this finding affects your work: It shows you that you have to decompose the user stories further and it suggests that the development team’s involvement in getting the stories ready should be improved – otherwise you would have spotted the issue before the stories went into the sprint.

If you had not been in the retrospective would you then whole-heartedly support the resulting improvement measures and change the way you work?


Be an Active Participant

Don’t attend the retrospective as a guest who will speak when asked but otherwise remains silent. Be an active participant, use the sprint retrospective to get feedback on your work, and raise any issues that you want to see improved. Be constructive and collaborative but don’t shy away from tough problems.

POAsActiveRetroAttendee

Here are some questions that you may want to explore in the retrospective:

  • Do you spend enough time with the development team? Are you available to answer questions or provide feedback quickly enough? Do you provide the right level of feedback and guidance in the right way?
  • Is the communication between the team and you open, honest, and trustful?
  • Does the team know how the users employ the product?
  • Are the team members happy with their involvement in analysing user feedback and data, changing the product backlog, and getting stories ready for the sprint? Do you get enough support from the team to “groom” the backlog?
  • Are the team members aware of the big picture – the overall vision, the product strategy, and the product roadmap? Do you get enough of the team members’ time to help you with product planning and product roadmapping?

Improve the Wider Collaboration

As important as it is, continuously improving your collaboration with the development team and the ScrumMaster is usually not enough. You also need strong relationships with all the other people required to make the product a success. These include individuals from marketing, sales, customer service, finance, and legal, as the following picture shows.

POWiderCollaboration

A great way to review and improve the collaboration with your partners from marketing, sales and so forth is to invite them to the retrospective on a regular basis. Depending on how closely you collaborate, this may range from once per month to once per major release. A joint retrospective will help you develop closer and more trustful relationships, help smooth the launch of new product versions, and improve selling and servicing the product.

Here are some questions that you may want to explore in an extended retrospective:

  • Are the partners from marketing, sales etc. involved enough in the product planning and roadmapping activities?
  • Do they regularly participate in the sprint review meetings? Are the review meetings beneficial for them? Do they understand the project progress?
  • Do they receive the information necessary to carry out their work in a timely manner, for instance, to prepare the marketing campaign and to compile the sales collateral?
  • Do you get enough data and support from the partners, for instance, regular updates on the sales figures and the market feedback you require?

You can, of course, also discuss these questions one-on-one. But getting any issues on the table and discussing improvement opportunities creates a sense of we-are-all-in-this-together; it reaffirms the need for collaboration and teamwork to provide a great product; and it can break down departmental boundaries.


Learn More

You can learn more about the sprint retrospective meeting and the product owner by attending my Certified Scrum Product Owner training course. Please contact me if you want me to teach the course onsite or if you would like me to run a product owner workshop at your office.

SprintGoalTemplateFeaturedImage

I find it helpful to consider three questions when choosing a sprint goal: Why do we carry out the sprint? How do we reach its goal? And how do we know that the goal has been met? My sprint goal template therefore consists of three main parts: the actual goal, the method employed to reach the goal, and the metrics to determine if the goal has been met. It additionally provides a header section that allows you to state to which product and sprint the goal belongs, as the picture below shows. You can download the template as a PDF from romanpichler.com/tools/sprint-goal-template/ or by clicking on the image below.

RomansSprintGoalTemplate

The template above has grown out of my experience of working with Scrum for more than ten years, and it is inspired by the scientific method and Lean Startup. Let’s have a look at the template sections in more detail.


The Goal Section

The goal section states why it is worthwhile to undertake the sprint. Examples are:

  • Test an assumption about the user interaction and learn what works best for the user, for instance: “Will users be willing to register before using the product features?”
  • Address a technical risk such as: “Does the architecture enable the desired performance?”
  • Release a feature, for instance: “Get the reporting feature for general release.”

The sprint goal hence differs from listing the user stories that should be implemented. It communicates the reason for carrying out the work, and it provides a motivation for running the sprint. The sprint goal should be shared: The product owner and the development team should believe that working towards the goal is the right thing to do.

To choose the right sprint goal I find it helpful to consider the amount of uncertainty present. In the early sprints, addressing risks and testing assumptions allows me to learn about what the product should look like and do and how it is built. Once the key risks and critical assumptions have been dealt with, I like to focus on completing and optimising features, as the following picture shows:

ChoosingTheRightSprintGoal


The Method Section

This section addresses the question of how the goal is met. The default Scrum answer is simple: Create a (potentially shippable) product increment using the high-priority product backlog items, and demo it to the stakeholders in the sprint review meeting. But writing software and employing a product demo are not always the best methods to achieve the goal! A paper prototype can be good enough to test a visual design idea or an assumption about the user interaction, for instance. What’s more, other methods such as carrying out a usability test or releasing software to run an A/B test may well be more effective than a product demo. You should therefore carefully choose the right method and state it in this section.

But don’t stop there. Determine the test group, the people who should provide feedback and data. Who these individuals are depends on the sprint goal: If you are validating an assumption about the visual design, the user interaction or the product functionality, then you probably want to collect feedback and data from the users. But if you are addressing a technical risk, then users may not be able to help you. Consider inviting a senior developer or architect from another team instead. Stating the test group clarifies who “the stakeholders” are, who is required to provide feedback so that the right product is developed.


The Metrics Section

The metrics section communicates how you determine if the goal has been met. Which metrics you use depends on the method chosen. For a product demo, you may state that at least two thirds of the stakeholders present should respond positively to the new feature, for instance; for a usability test, at least three of the five testers are complete the task successfully in less than a minute; and for the release of a new feature, you might say that at least 80% of the users use the new functionality at least once within five days after launching the feature.

Whichever metrics you choose, make sure that they allow you to understand if and to which extent you have met the goal.


The Header Section

The header section consists of the two subsections “Product” and “Sprint”. They simply allow you to state which product and which sprint the goal belongs to.

Customise this section according to your needs. If you work for an agencies or an IT solution provider, you could replace “Product” with “Project”, for instance.


User Stories and the Sprint Goal

You may be wondering how the template relates to the user stories. Let me first reiterate that your sprint goal should differ from your user stories. The goal explains the why it is a good idea to carry out the sprint an implement the stories. The user stories enable you to reach the goal. It’s a common mistake to confuse the two.

To connect the template and the stories you have two options: You can state the relevant user stories in the template’s method section, or you can list them separately on the sprint backlog, as the following picture illustrates.

SprintGoalAndSprintBacklog

In the picture above, the sprint goal is stated on the left to the sprint backlog, which lists the user stories and the tasks required to meet the goal in form of a task board.


Learn more

You can learn more about choosing effective sprint gaols and applying the sprint goal template by attending my Certified Scrum Product Owner training course. I have written in more detail about sprint planning in my book “Agile Product Management with Scrum”. Please contact me for onsite and virtual product owner training.

10PersonaTipsFeaturedImage

1. Start with Provisional Personas

As its name suggests, a provisional persona is not a fully-fledged, detail rich user model, but a first version that is good enough to start discovering the right user experience and the right product features. Working with sketchy but good enough personas is particularly helpful in an agile and lean context where we want to very quickly test our assumptions, rather spending a lot of time with upfront market research.

To get started, learn enough about the users and customers by employing, for instance, direct observation and problem interviews. While your initial personas can be sketchy, they should be based on market insight and nor speculation. With your provisional personas in place, gather feedback on prototypes, product increments, and MVPs to validate and adapt your personas. As you run more iterations, your personas should become more refined. The following picture illustrates this process:

ProvisionalPersonaProcess

Note that provisional personas are different from proto-personas, as defined by Jeff Gothelf, as proto-personas are not necessarily based on user research.

2. Keep your Personas Concise

It’s easy to add more and more detail as you create your personas: Enriching the description and adding, for instance, another cool spare time activity or a cute pet can be so much fun. While your personas have to contain enough information to be usable, too much detail bloats them, and they become difficult to work with.

Only include information that is relevant, that helps you make informed decisions about the user interactions, the visual design, and the product functionality. Leave out the rest. My simple, minimalist persona template wanst to help you write concise personas (you can download the template by clicking on the picture):

RomansPersonaTemplate

3. Distinguish User and Customer Personas

Create separate user and customer personas whenever the users and the customers are not the same people. This allows you to capture the user and the customer-specific needs, and it makes divergent or conflicting goals easier to see.

Say we want to develop a new, advanced X-Wing Fighter. The pilots would want a plane that’s easy to fly and well protected. But the purchase department of the Rebel Alliance is likely to be concerned with the purchase price and the maintenance cost. Employing two different personas allows us to model the user and the buyer, and to state their different goals.

4. Choose a Primary Persona

Whenever you create several personas for a product, choose one primary persona. The primary persona is the character you mainly design and build the product for. Say we choose Luke, the pilot, as the primary persona in the X-Wing Fighter example above. Then meeting Luke’s goal – creating a plane that’s easy to fly and well protected – becomes our top priority. But if we choose John, the purchase guy, as the primary persona, then the resulting product would be very different.

PrimaryPersonaLuke

5. Make your Personas Believable

Your personas should help the development team cultivate empathy for the users and customers, and to view the product from the user’s perspective. To achieve this, your personas have to be believable. There are three practices that help you create believable personas:

  • Base your personas on user research.
  • Respectfully choose a persona’s name, picture, and characteristics.
  • Refine personas together with the development team.

 

6. Identify the Main Benefit or Problem

I frequently see personas that contain a lengthy list of problem and benefit statements. While is it is perfectly OK that a persona description provides more than one problem or benefit, I recommend selecting one main problem or benefit – the true reason why the persona would want to use or purchase the product. This creates focus and facilitates effective decision-making.

7. Test your Personas

Validate your persona descriptions, as you lean more about the users and customers and their needs by building prototypes, product increments, and MVPs. This is particularly useful in an agile and lean context, where you want to minimise the amount of initial market research to quickly test your crucial ideas.

Adjust and refine your personas when you decide to persevere. But rewrite your personas or start with brand-new ones if you have to pivot and change your strategy.

8. Connect Personas and User Stories

Make the most of your personas, and use them in the scenarios, the storyboards, the workflows, and the user stories you discover. The following format helps you connect your personas with your user stories:

StoryTemplate

9. Visualise your Personas

Make you personas visible and accessible to everyone involved in the development effort. I find working with paper-based personas very beneficial, and I like to put them on the Product Canvas.

PersonasOnTheProductCanvas

10. Recognise when Personas are not Appropriate

While personas are a powerful tool, there are instances when they are not appropriate. If you create a product that serves a small user group, then working with personas not be necessary. Similarly, if your product does not have any end users, the employing personas is not advisable.

Take a client of mine that develops a physics engine, software responsible for the clever animations in computer games. The users of the software are games developers who integrate the engine into their code. Creating personas for the physics engine is not beneficial in my mind. But for the entire game it is, of course.


More Information and Help

You can learn more about working personas in an agile and lean context by attending my Certified Scrum Product Owner an Product Canvas training course. The courses are also available for onsite delivery. Please contact me for more information.

10 Persona Tips for Agile Product Management by Roman Pichler is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
Based on a work at http://www.romanpichler.com/blog/10-persona-tips-agile-product-management/.

InnovationVsMaintenance

Creating new features and maintaining existing ones are different types of work: The former requires dealing with uncertainty, acquiring new knowledge, and carrying out experiments. Making small, incremental changes entails few unknowns, and the work should be done with minimum effort and no failures or mistakes. I therefore prefer to apply different approaches for the two types of work, as the following picture illustrates:

InnovationAndMaintenance

The picture above shows two workflows: In the upper workflow, a feature team turns new features into a new product version using a cyclic process. In the lower workflow, a maintenance team fixes bugs and carries out small enhancements using a linear process.

The bugs above are taken from: http://yprl.vic.gov.au/sites/default/files/uploads/blogs/mill-park-news/ladybugs.jpg

Separate Teams

To deal with innovation and maintenance work for the same product, I have a preference to work with a feature and a maintenance team, as this creates focus and it reduces task switching. It allows the tem members working on new features to carry out focussed experiments, and it makes it easier for those doing the maintenance work to fix the bugs quickly. If you work with one small team, then consider forming two sub teams – particularly once the maintenance effort consumes more than 25% of the team’s capacity.

A danger of employing separate teams is the creation of a two-class society with the cool feature developer doing rad innovation work, and the poor old maintenance guys slaving away at mind-numbingly boring bug fixes. To mitigate this risk, the feature and maintenance team members should rotate regularly. This also encourages knowledge sharing and collective ownership.

How often and how many people rotate is best determined on a case-by-case basis. For instance, two to three people could swap places at the end of each week or at the end of each fortnight, depending on which solution best balances team cohesiveness and knowledge sharing.

Separate Processes

Innovation and new feature development requires the ability to develop and test assumptions, to gather and analyse data, and to leverage the new insights. In other words, the feature team requires an iterative process such as Lean Startup or Scrum. (Please see my post “New Product Development with Lean Startup and Scrum” for a discussion how the two approaches can be combined to create new products and features.)

Making small enhancements and bug fixes, however, does usually not require a cyclic, feedback-driven process, as there is little uncertainty present. Instead, the changes should be implemented and deployed in a fast and efficient manner. A linear, Kanban-based process is ideal for this job in my experience.

As a consequence, you may want to use a Product Canvas to capture the new features, and a product backlog to describe and manage the maintenance work. Similarly, the two teams should use separate boards: one for the new feature development, and one for the maintenance work.

Joint Ownership

While using separate teams and processes for feature development and maintenance work can well be beneficial, separating product ownership is something you should avoid. I have intentionally positioned the product owner between the two workflows in the picture above, as the individual should own the existing product and the new product version. As the product owner, you should hence balance the two concerns and decide how much effort is spent on new feature development vs. maintenance in a given timeframe.

As the product owner, carrying out new feature development and maintenance work in parallel may be your only choice. But maybe you are able to focus on maintenance work for a certain period and do what I sometimes call a “Snow Leopard”: a maintenance release dressed up as a new product version. Use a product roadmap to manage the two types of work across product versions, and to document how much effort you intend to spend on maintenance.

If dealing with new feature development and maintenance is too much work for one person, then consider employing a product owner team with a chief product owner, or break up your product into vertically aligned parts with a product owner looking after one of the newly formed sub-products. Whichever solution works best for you, ensure that there is joint ownership so that both concerns are managed well.

Summary

The following table summarises my recommendations for managing new feature development and maintenance work:

InnovationAndMaintenanceSummary

You can learn more about succeeding with innovation and maintenance work by attending my Certified Scrum Product Owner training course.

Learning Vs Execution

Learning what a product should look like and do, and building solid, shippable software are different concerns. Separating the two aspects and distinguishing between learning and execution helps you manage the stakeholder expectations, select the right research and validation techniques, and choose the right sprint goals.

Learning vs. Execution

When we start developing a new product or new features, there are usually more unkowns than knowns, more things we don’t know than we know: We may not be clear on the user interaction, the user interface design, the product’s functionality, or the architecture and technology required to build the product. Our greatest challenge is therefore to deal with the uncertainty present, and the associated risks.

As a consequence, the early sprints should focus on creating the relevant knowledge, and addressing the key risks. Selecting a testable idea (hypothesis), and running an experiment are great ways to achieve the necessary learning. As testing ideas results not only in success but also in failure, you should expect to fail in the early sprints. Your Product Canvas or backlog, and your architecture are likely to see bigger changes driven by the newly gained insights.

As you acquire more knowledge, your focus should gradually shift from resolving uncertainty towards execution: building a product that is ready for general release. Rather than primarily testing ideas, you should now start completing features and incrementally adding new ones. Failure can still happen at this stage, but it is usually a sign that something has gone fundamentally wrong. Similarly, your Product Canvas or backlog should have started to stabilise and exhibit less volatility. The change of focus may also impact your Definition of Done: Throwaway prototypes used to test ideas quickly don’t have to have the same quality as software that will be shipped. You can now start ramping up the project, add new teams, and consider employing distributed teams.

The following picture visualises the relationship between learning and execution for the development of a new product or a new product version:

To understand how much learning and experimentation is required, consider the amount of innovation present and the technologies used: A brand-new product usually requires more experimentation than a product update; and a web app developed with standard technologies is faster and easier to create than an embedded system or a mainframe application (assuming that some market research or problem validation has already taken place).

Benefits

Understanding the relationship between learning and execution has three main benefits:

First, it allows you to set and manage stakeholder expectations. It helpful for the stakeholders to understand that the early product increments are likely to be throwaway prototypes, and that failure is to be expected in the first few sprints.

Second, it helps you choose the right sprint goals, and focus the work of the development team: Your early sprints should acquire the relevant knowledge by carrying out experiments. You later sprints should build features and get the software ready for general release.

Third, it makes it easier to select the right research and validation techniques. You may want to work with user tests and product demos in your early sprints, and with releasing software to selected users in the later ones.

Summary

Innovation – creating a new product or new features – involves uncertainty and risk. To build the right product with the right features quickly, you should make a concentrated effort in your first few sprints to quickly address the key risks and acquire the relevant knowledge. Then shift your focus to completing features and adding new ones by creating software that can be released.

You can find out more about learning and execution in Scrum by attending my Certified Scrum Product Owner training course.