Tag Archives: market research

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.

FearuredImageWorkingwithGORoadmap

Step 1: Do the Prep Work

Before you create your GO product roadmap, you should carry out the necessary problem validation work. Investigate the target group, the problem to be solved, the business goals, and the technical feasibility of your product. The Vision Board, the Business Model Canvas, and the Lean Canvas are great tools to capture and validate your ideas.

VisionBoardGOProductRoadmap

To see how this can work in practice, take a look at the Vision Board below. The board captures the idea of creating a digital dance game together with the intended audience, the benefits, the key features, and some aspects of the business model:

DanceGameVisionBoard


Step 2: Build the Roadmap

The Vision Board, Business Model and Lean Canvas are helpful tools to describe the market, the value proposition, and the business model. But they not tell us how the strategy will be executed. Will the first product version deliver the entire value proposition and generate the desired business benefits, for instance, or will this take longer? Say we focus the first version of the dance game on user acquisition. While this is a necessary step towards the vision, it does not answer the question when revenue will be generated. This is where the GO roadmap comes in.

I used the Vision Board above to create the roadmap shown below. You can download a PDF and Excel template by clicking on the picture.

DanceGameGORoadmap

The roadmap above takes the Vision Board contents, and shows how the strategy is executed over the next 12 months. It states the planned major releases with their goals, key features, and metrics. Version 1, for instance, is focussed on user acquisition, version 2 on activation and revenue generation. Version 3 is about retaining existing users, and version 4 targets a new segment and tries to acquire new users. (I discuss in more detail in my post “The GO Product Roadmap”.)

Your roadmap should tell a coherent story about how the product is likely grow: Choose the goals carefully and consider their relationships.

Which timeframe your roadmap should cover and how often you want to create a major release / new product version depends on your product. You should be reasonably confident about your roadmap and avoid speculation. You can regard the roadmap goals as hypotheses, but they should be informed assumptions, and not wild guesses.

If you cannot look further than the next release, then do not employ a roadmap!


Step 3: Derive your Product Canvas/Backlog

With your GO roadmap in place, you can now take the next step and use the product roadmap to stock your Product Canvas or product backlog. The GO roadmap provides you with the goal for the next major release, the two to three key features, and the metrics, which are a great starting point for discovering the product details including the user journeys, epics, the visual design, and the nonfunctional requirements.

GOProductRoadmapProductCanvas

The GO roadmap connects the Vision Board / Business Model Canvas to the Product Canvas/backlog; it links market insights and business model with the product. What’s more, the roadmap allows you to focus your Product Canvas/backlog on the next major release, which results in a smaller and more manageable canvas/backlog that is easier to change and update.


Step 4: Pivot or Persevere?

The process I have suggested so far sounds rather sequential: Do some problem validation work, then build the roadmap, and derive the Product Canvas to develop the product. This may give the impression that the GO product roadmap is a fixed plan that simply has to be executed. But the opposite is true.

Whenever we create something new – be it a brand-new product or new features – the one thing we can be sure of is that our initial ideas don’t work out as planned. As you collect feedback from users and customers on your prototypes, product increments, and MVPs, you should always ask yourself if your product strategy is still valid.

Say we expose an early prototype of the dance game to a test group. But unfortunately, we have to recognise that the kids are less excited by the game and playing it much shorter than anticipated. This data should make us rethink our strategy by asking ourselves if our market assumptions (segment and problems/needs) are wrong or if the user experience provided by the product is adequate. In both cases we have to pivot and change the strategy together with the product roadmap, as the following picture shows.

GORoadmapPivot

Note that the picture above assumes that the Vision Board / Business Model has to be changed in addition to the roadmap. That’s not necessarily true if the UX or features of the product are inappropriate but the market and business model-related assumptions are valid.

Be prepared to throwaway your existing GO product roadmap and to create a new one.

To minimise any rework, do the necessary problem validation work recommended in step one, and keep your product roadmap focussed and concise. The more details you add the more attached you become to your roadmap, and the harder it is to let go.

Once you have reached product-market fit and are confident that you are building the right product for the right people, I recommend you review and adjust your roadmaps on a regular basis, for instance every two months, as part of your portfolio management process.


Learn more

You can learn more about working with the GO product roadmap by attending my Agile Product Planning training course.

Please contact me for product roadmap workshops and webinars.

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/.

NPDProcessLeanStartupScrum

Discovering Lean Startup was inspiring for me: I felt I had found an approach that could complement Scrum nicely. Since then I have been combining the two approaches in my own new product development work as well as helping my clients to do so. This post shares my experiences and insights. It maps out a high-level process for creating new products within existing businesses focussing on product management practices and tools.

From Vision to Launch

Lean Startup encourages us to first investigate if there is a need worthwhile serving before we worry about the details of the new product. The former is called “Problem Validation”, the latter “Solution Validation”. While traditional approaches also suggest carrying out market research and analysis before we engage in product planning and definition, lean approaches increase the speed at which we operate. This allows us to fail and learn faster, to adapt our product strategy and tactics quickly, and to hopefully launch the right product with the right features sooner.

The following diagram illustrates the process I apply to create new products:

Problem Validation

The new product development process depicted above starts with a vision. It then uses a series of cycles or iterations to transform the vision into a product ready for launch. The focus of the early iterations is to understand what problem the product solves, who the customers and users are, and how the product benefits the company creating it.

I find it important that the product owner leads this effort and carries out the necessary work together with a cross-functional team. While the team composition depends on the product, having a marketer, sales representative, service representative, a UX designer, and a developer on board is usually helpful. Product owner and team capture their assumptions about the market by using a tool like the Vision Board, Business Model Canvas, or Lean Canvas.

Employing techniques such as direct observation, problem interviews, and competitor analysis helps them validate their assumptions and update the board or canvas, as the following pictures illustrates:

Additionally, the developers may create spikes (throwaway prototypes) to explore the feasibility of the product. Target users and customers participate in the process, for instance, by acting as interview partners.

Solution Validation

Once product owner and team have shown that there is a problem that’s worthwhile addressing, the focus changes to validating the solution and developing the actual product: The team needs to learn what the desired user experience is, what functionality the product should provide, and how it should be built.

The new focus requires adapting the team composition: The product owner, the UX designer and the developer stay, but the marketer, sales and service representatives leave the team. They continue to participate in the development effort as stakeholders. New developers, testers, and other roles required to create a great product join the team.

Product owner and team capture their assumptions about the product including the user interaction, the user interface design, the functionality, and the nonfunctional aspects using a tool like the Product Canvas and techniques such as scenarios, user stories, and design sketches. The assumptions are tested by collecting and analysing feedback on prototypes, mock-ups, and product increments/MVPs. Useful techniques to gather the feedback include product demos, users tests, and releases (to selected users).

As you may have noticed, the picture above suggests that “Stakeholders incl. users” participate in the process, and provide feedback or data on work results. While using target users and customers to validate ideas is generally helpful, it is not always appropriate. Imagine addressing a key technical risk in your first solution validation iteration: It probably makes little sense to invite users to the review meeting to understand if the approach chosen is viable. Similarly, if a disruptive product is developed it can be hard to find target users that are not too attached to their current solution.

Scaling and Launch Preparation

Once the Product Canvas and the architecture have started to stabilise, you can start adding more people to the project. I find it useful to break-up the original team so that at least one or two members are part of each new team, as this helps the new members get up to speed. I also suggest you grow your new product development project in a step-wise fashion: Scale from one to two teams, then from two to four, and so forth. This allows you to understand the impact on the people and the process including product ownership .

Be aware of the danger of premature scaling: Adding too quickly too many people. This tends to lead to a bloated, over-engineered product in my experience, and it prevents you form being able to experiment effectively. Therefore delay scaling until you have resolved the main risks – until you can focus on completing features and adding new ones.

Finally, as you make progress with your solution validation work, don’t forget to prepare the product launch. Having a marketer present at the sprint review meetings should help, but you may find that a dedicated marketing may be required to prepare and execute the launch well.

Summary

The following table summarises my recommendations for transforming an idea into a shippable product:

The process described in this post is based on work by Steve Blank, Ash Maurya, Eric Ries, and Ken Schwaber. The eagle-eyed process historians amongst you may have noticed that the idea of progressive scaling has its roots in the (Rational) Unified Process. Experimental, iterative product development has been around for quite some time of course, I believe at least since the late 19th century when Thomas Edison established the Menlo Park laboratory.

You can learn more about combining lean and agile techniques to create new products by attending my Agile Product Management training course. Please contact me for onsite workshops.

If you have any feedback, comments, or questions, then I’d love to hear from you!

Product Canvas Creation Workshop Overview

The Product Canvas is a simple, yet powerful tool that helps you create a product with a great user experience and the right features. This post explains how you can create your initial canvas using a collaborative workshop.

Note that many of the recommendations below also apply to other agile and lean product definition tools including a traditional product backlog.

Overview

The Product Canvas creation workshop wants to kick-start your solution validation and product definition activities. It helps you change the focus from problem validation – exploring if there is a need that the new product addresses – to building a product with the right features and the right user experience. The following picture summarises the workshop, and the rest of this post explains the details.

Attendees

Everyone tasked with creating the product should attend the canvas creation workshop: the product owner, the team developing and testing the product, and the ScrumMaster or coach. This creates shared ownership, and it is likely to result in better decisions, as the entire team’s creativity and knowledge are leveraged.

I generally recommend that the stakeholders – the users, and customers as well as the internal stakeholders – do not attend the workshop, but share their ideas and feedback based on prototypes and product increments, for instance, in the sprint review meetings. This allows the product owner and the team to be creative before the stakeholders provide input.

Input

Before you start the workshop, you should be able to confidently answer the following questions:

  1. Who are the product’s users and who are the customers?
  2. What problem does the product solve? What benefits does it generate for its users? What is the product’s value proposition?
  3. What business benefits does the product creates? Why should the company invest in it?
  4. What kind of product is it? What are the three to five features that make it stand out?

I like to capture the insights above using the Vision Board. But you can also employ other tools including Ash Maurya’s Lean Canvas and Alexander Osterwalder’s Business Model Canvas, as the following picture shows:

Being able to answer the questions above means that some problem validation has taken place prior to the workshop, for instance, by carrying out user observations and problem interviews. Note that the strength of the Product Canvas is solution validation – building the right product – and not discovering if the product should be built in the first place!

To ensure a smooth workshop, use a facilitator, for instance, the ScrumMaster. Organise an appropriate room with lots of wall space. Have the necessary materials available including paper sheets, paper cards, adhesive notes, masking tape, markers, and pencils. Starting out with paper and pencil is effective and fun in my experience, even if you intend to use a digital canvas.

Steps to Create the Canvas

To create your initial Product Canvas take the following three steps: Create personas; outline the user experience and the features; determine what to do in the first sprint, as the picture below shows:

The first step creates personas based on the insights gained in your problem validation work. The personas allow you to connect with the target users and customers. Their needs enable you to discover the right product features. I also recommend using a primary persona, as it creates focus and facilitates decision-making. You can read more about personas in the post  “A Template for Writing Great Personas”.

The second step describes the product comprehensively but at a rough, coarse-grained level. Helpful techniques to capture the user experience and the product functionality include scenarios, storyboards, epics, constraint stories, and design sketches / mock-ups. Make sure that the product features you identify address the need of a persona, or support the business model.

The third step determines what should be done in the first sprint. As you are about to start building the first product increment, you should address the greatest risk or the biggest uncertainty. This could be a lack of knowledge surrounding the user interaction, the user interface design, a product feature, or the architecture and technology. See my post “Effective Sprint Goals” for more information on choosing the right goal or hypothesis. Finally, determine what needs to be done to reach the goal, or to test the hypothesis, for instance, creating a scenario and a paper prototype to learn more about the user interaction.

The three steps above form a breadth-first approach: The product is sketched holistically, but the details are determined on a sprint-by-sprint basis. This keeps your canvas concise, and allows you to make changes quickly and effectively.

Outcome

At the end of the workshop you should have a Product Canvas that is good enough to start sprinting: to start building product increments/MVPs, gathering feedback, and integrating the insights gained, as the following picture shows:

Make sure you create a good-enough canvas, but not a perfect one. Your Product Canvas will change and evolve anyway based on the feedback you receive!

Duration

Four to eight hours should be enough time to create your initial canvas. If you require more time, then this may be a sign that you haven’t got enough information available and may have to carry out more problem validation and market research.

Summary

Employing a collaborative workshop, and following the process described above creates an initial Product Canvas that allows you to focus on solution validation – building the product with the right user experience and features. Make sure you understand the product’s value proposition before you enter the workshop, describe the product holistically at a coarse-grained level, and don’t worry too much about the product details: These will emerge incrementally based on the feedback you gather.

You can learn more about the Product Canvas creation workshop by attending my Certified Scrum Product Owner training course. If you would like me to help you run a Product Canvas workshop, then please contact me.