Tag Archives: startup

 “This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit-hole goes,” says Morpheus to Neo in the movie “The Matrix”. This quote reminds me of the choice we face when dealing with a new product idea: Should we walk away from it, or should we jump into it? And how can we tell?

To help product owners and teams decide if and how to progress an idea, I have developed a tool called the Vision Board. The board captures important assumptions that influence the product success, and it allows teams to start testing and refining their ideas. In this post, I explain how the vision board can be applied to kick-start the innovation process and to create a new software product.

A New Product Idea

I’ve recently had the idea of developing an electronic tool, a digital version of the Product Canvas. The canvas is a multi-dimensional product backlog that allows teams to properly capture the user experience including the user interaction and the user interface design. Since I published the canvas in July 2012, I have received lots of encouraging feedback. Some of it suggested an electronic version, and Johan Steenkamp started to work on a free, web-based product canvas as part of his BMFiddle.

After loosely collaborating with Johan for a couple of months, I was wondering if an enhanced digital canvas would be a good idea. It was like weighing up which pill to take: Take the blue one and leave the tool development to Johan, or take the red one and commit time, money, and energy? To help me make the right choice, I created a vision board for a new electronic product canvas. But before I introduce the board to you, let me briefly remind you what the vision board is all about.

The Vision Board Reloaded

The product vision board captures the initial ideas and assumptions for a new product, as the following picture illustrates.

The board above describes the overarching vision that guides the product. It states who should use and purchase the product (Target Group), why people would want to use and buy it (Needs), what the key product features are (Product), and why the organisation should invest money in the product (Value).

It’s important to understand that the vision board is intended to initiate the innovation process. It does not want to describe the users, the product, and the business model comprehensively or in great detail. It rather captures the critical assumptions, those assumptions that will make or break the product. More information is provided later in form of the Product Canvas and the Business Model Canvas, as the following picture illustrates.

Creating the Vision Board

To clarify my thoughts, I sat down and created a new product vision board. While I am a great fan of simple, physical tools, I decided to create an electronic vision board, as I wanted to share the board with Johan who lives in New Zealand, whereas I am based in the UK. Here is what I came up with:

 To create the board, I started with the vision statement keeping it intentionally broad. This allows me to follow the vision even if my electronic tool idea turns out to be ill conceived. At the same time, the vision reminds me that the new product is only means to an end: to help organisations create great products.

 Next I recorded my ideas about the users. In addition to product managers and product owners, individuals setting up their own business might find the tool helpful. As I am particularly unsure about this group, I have marked it in italic. I use this convention on the other sections of the board, too.

 I then focussed on the user needs formulating them as goals, for instance, being able to share the canvas with remote team members. Note that I have ranked the needs according to my current knowledge. Additionally, I have introduced a barrier: I believe that concerns about intellectual property and data theft may prevent people from using an electronic canvas. If the assumption is correct then it’s likely to have an impact on the solution and on how it is marketed.

 In the next step, I listed those product features, which I consider to be particularly important to create value for the users. I was careful not state a specific solution such as an iPad app, or a web app. This would be premature at this point in time and narrow down the options too quickly. Before I decide on the product specifics, I want to validate the needs of the target group first. As a consequence, the vision board may change based on the new insights.

 Finally, I stated the motivation for my business to invest in an electronic canvas tool. Similarly to the other sections, I have tried to focus on what I believe are the key assumptions and not be tempted to design the business model before I haven’t learned more about the users and their needs. After all, the business model will only work if the needs are met well!
I also found it helpful to state what I view as an investment barrier: If the electronic canvas tool incurs high running cost then this is likely to prevent me from funding the product development effort.

Validating the Vision Board

The next step for me is to validate my assumptions starting with the most critical one: the target group and the needs. I am planning to conduct a series of problem interviews focussed on the issues product owners and managers experience today when they identify, capture and modify requirements, as the picture below shows.

Problem interviews focus on the user needs, their goals and pain points rather than the product itself. In fact, it’s a good idea to exclude any product validation form the problem interviews, and not to ask, for instance: “Would this feature be helpful?” There are other research techniques, of course, for instance, observing users, but I am confident that interviews are adequate for now.

The interviews will hopefully help me validate my assumptions and allow me to learn more about the users. This should enable me to narrow down the solution and decide, for instance, to develop an iPad application, as well as help me find a viable business model. As Morpheus puts it: “Welcome to the desert of the real.” For as long as we just assume and hypothesise, we live in a dream world. By testing our ideas, we face reality.

Get Involved

If you would like to share your experience working with product boards, canvases, or backlogs, if you have any thoughts about what an electronic tool should do for you to capture, test and refine your product ideas, or if you have any specific questions about the Product Vision Board or the Product Canvas, then I’d love to hear from you. Please drop me a line either by email or via Twitter.

You can learn more about applying the product vision board by attending my Agile Product Management training course.

With the term startup we usually associate starting a new company and pursuing a new idea with a small, creative team. While Scrum has been used for many years in startup companies – companies with a limited operating history – I have found that setting up a Scrum team as a “startup” or incubator within an established enterprise is a powerful approach to create a new product, and to pilot a new way of working.

A Scrum Startup consists of the product owner, the ScrumMaster and the development team. Together, they form is a self-contained unit that is loosely coupled to the rest of the organisation and in charge of developing and releasing the product. The product owner acts as an intrapreneur, an entrepreneur within the larger organisation.

An Enterprise Scrum Startup

The first Scrum project I helped run in 2004 had ambitious plans: It was tasked with creating a new enterprise telecommunications software product. The company had high hopes for the product: It was considered vital to the business group’s future. To create an environment that encouraged innovation and creativity, we opened up a new development site, and assembled a new team.

We also made sure that the product owner was able to act as an intrapreneur and received the backing from senior management. The individual had a vision for the new product and a budget to turn the vision into reality. The Scrum Startup controlled the product under development including the development and test environment, and it experienced few changes to the team composition. The individuals had a personal stake in the outcome: Everybody desperately wanted the new product to succeed knowing that it would shape future of the group.

We didn’t quite realise it, but we had created a startup within a well-established, large enterprise: Siemens, a company which has more than 420 000 employees and which is over one hundred years old. The resulting product became part of OpenScape Unified Communications. It has won a number of awards, and is still selling well.


Setting up a Scrum team as an incubator is so powerful as it disentangles the team tasked with innovating from the rest of the organisation. Think of a Scrum Startup as a new house in the enterprise village, or a new tree in the corporate garden.

The members of the Siemens telecommunications project were free to literally think outside the box, to try out new things, and to be creative. Most importantly, it created a safe environment for experimentation: for testing new ideas and for failing. Our first minimal viable product (MVP), the product increment of the second sprint, turned out to be a failure: We had chosen the wrong component technology, and the product did not live up to the users’ performance expectations.

Our first process experiment ended in failure too: We had started using a heavily tailored, lightweight version of the Rational Unified Process (RUP) that included development practices from Extreme Programming. After a few iterations, we decided to switch to Scrum. The RUP iteration management and collaboration practices simply did not work for us.

Without those early failures and the learning that they enabled, we probably would have not been able to deliver a successful product.


As important as autonomy is, it needs to be balanced with collaboration: working together within the Scrum Startup and with the stakeholders. A healthy, trustful relationship between the product owner and the team, the product owner and the ScrumMaster, and the ScrumMaster and the team is a prerequisite for applying Scrum successfully and for creating a great product. But it’s no less important to invite internal stakeholders to participate in the development process, and to use the feedback from target customers and users to create a product with the right features for the right people.

When we created the telco product, we invited representatives from marketing, sales and service to the sprint review meetings, and we demoed MVPs to other development groups destined to build on the product. Releasing early product increments to employees in other parts of the enterprise is another great way to benefit from the ideas of the rest of the organisation, and to keep people informed about the progress. Exposing product increments early and frequently to target customers and users in form of demos or releases helps to achieve a great product market fit.

Scrum Startup Qualities

To help your enterprise Scrum Startup succeed, make sure it fulfils the following four properties: It should be loosely-coupled to the enterprise and in control of the product; the people working on the product should have a personal stake, and the incubator should be stable. The following image depicts the four qualities:


Reflecting on more than ten years of experience using agile techniques to create products and helping organisations establish Agile, I am convinced that combing the introduction of Scrum with a new product development effort and setting up the Scrum team as an incubator can facilitate product and process success. Give it a go, and let me know how it’s working for you.

I find the Lean Startup concept of a minimal viable product (MVP) rather exciting: It entails creating a first product version to test our ideas as quickly and cheaply as possible. This could be a throwaway prototype such as a mock-up or a product increment, working software that is tested and documented. The MVP works together with a build-measure-learn cycle: developing software, gathering customer feedback, and learning from it.

Build, Measure, Learn

With roots in the Scrum tradition, this sounds rather familiar to me: Validating assumptions by gathering customer feedback using product increments is called empirical management or inspect-and-adapt in Scrum.

But Scrum advocates the use of a product backlog containing the outstanding work necessary to create a successful product. How does the backlog fit into the picture? And can the product backlog be helpful to create a minimal viable product?

This blog posts answers this question and investigates how Lean Startup and Scrum concepts can be combined successfully.

The Product Vision

“If I had asked people what they wanted, they would have said faster horses,” said Henry Ford famously. A vision, an idea of the future product, is the start of any successful innovation. Without a vision, we lack a shared goal, a common direction.

To reach our goal, we have to decide on an approach or strategy. This includes making assumptions about the target group, the needs the product should address, the key product features, and the value it should create for the organisation developing. I use my Vision Board to capture and visualise the product strategy.

The strategy’s assumptions must be validated. A great way to do this is to create the minimal viable product and to release it to the target customers and users.

The Product Backlog

Unfortunately, the product strategy is often too coarse-grained and partial to be used as a direct input for writing software. It can therefore be helpful to take an intermediate step, and to identify the work that is required to validate the strategy.

The corresponding items are placed in a sketchy, lightweight product backlog. To put it differently, the backlog is derived from the product strategy; it makes the strategy implementable.

Vision, Product Strategy, Product Backlog

From Backlog to Minimal Viable Product

Once we have a strategy and initial product backlog available, we create the minimum amount of functionality necessary to test our assumptions. This may take a day or two, or one or more sprints with a preference for the shorter timescales. Our goal is to find out quickly if the product generates a positive response amongst the target users and customers, and if the target group members use the product in the intended way. Once we’ve created the MVP, we release it and gather the relevant data.

Strategy, Backlog, and MVP

Note that releasing the MVP can be limited to a small group of users if the respondents are representative for the target group. Google, for instance, released early versions of its Chrome browser internally and asked its employees to test the software and to provide feedback before a first public beta was released in October 2008. A counter example is Google Buzz: The software was apparently loved by Google engineers, but unfortunately not by the rest of the world.

Pivot or Persevere?

Once we’ve gathered and evaluated the feedback, we need to decide if and how to act upon it. If the feedback invalidates any assumptions in the product strategy – which is likely to be the case when a new product is developed – we should adjust it together with the product backlog. Making changes to the strategy is also called pivot.

We may decide to change the target group or the needs selected, for instance; maybe the features or the look and feel envisioned is not right; or the business model does not work as expected, for instance, users never click on the ads displayed. Changing the product strategy can require restocking the backlog. With the backlog updated, we continue with the next cycle, develop a new MVP, and gather new feedback.


If the data confirms our strategy, we preserve and adapt the product backlog by incorporating the insights gained. Depending on the quality of the MVP, we may have to throw away any mock-ups and prototypes created so far, and start afresh developing tested and documented software using agile development practices. If the MVP is a product increment, we can progressively transform it into a shippable product using a series of sprints.



Using a minimal viable product is a powerful concept to validate the product backlog that be used in harmony with Scrum’s approach of creating working software, exposing it to customers and users, investigating their feedback, and making the necessary adaptations. Many thanks to @stefanroock for feedback on the first MVP of this post.

If you’ve found this blog post interesting, you are likely to benefit from my Agile Product Management training. The course teaches a combination of Lean Startup, Scrum, Kanban, and Design Thinking techniques. Check it out!

To create a new product, we have to peek into the future and anticipate what the product will roughly look like and do. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult. After all, the only thing certain about the future is that it is uncertain! Investing in a new product hence always involves risk. We may have targeted the wrong market segment, envisioned the wrong product or the wrong features, or the market may have changed by the time the product is launched.

Envisioning a Lean, Minimal Product

A great strategy to minimise the investment risk is to envision a lean, minimal product with the smallest possible feature set. I refer to such a product as the minimal marketable product. It contains just enough functionality to be viable – to launch, market and sell the product successfully. Developing a minimal product is quicker and cheaper than a more ambitious, feature-rich one. If the product bombs less time and money is lost. If it is a success, the product starts earning money sooner. Additionally, a minimal product allows us to receive feedback earlier so we adapt the product quicker to the market response. Rather than trying to create the perfect product, we follow the motto “get it out, then get it right.” Note that the product’s quality must be right from the start. Otherwise it will be difficult to adapt the product; bugs may hinder its adoption, or even damage the brand.

The iPhone

An example of a minimal marketable product is the original iPhone, which launched in 2007. One of the secrets behind its success is the narrow set of customer needs Apple selected. The company avoided the trap of trying to please too many people at once, of trying to copy all the features competitors offered. Instead, Apple took a fresh look at what smartphones should look like and do, and deliberately left out some functionality. The original iPhone shipped without many features standard on existing phones: copy and paste, the ability to send text messages to multiple recipients, and a software development kit, for instance. These limitations, though, did not hinder its success. Paring down the functionality allowed Apple to develop and ship the product within a competitive timeframe and gave the company a significant lead over its competitors. Building on the success of the first iPhone version, Apple started to extend the capabilities of the phone both in terms of hardware and software with the launch of the 3G model in 2008. This version also allowed the company to enter a new market segment by targeting business users.

The Apple Newton

Developing a minimal marketable product may sound like a no-brainer. But my experience suggests that many start-ups and established companies alike find it hard to restrict the features of a new product. It’s often too tempting to opt for a big-bang release trying to satisfy as many users and customers at once in order to maximise revenue. Contrast the iPhone with another Apple product: the Apple Newton, first launched in 1993 after five long years of development. Remember those Apple ads that promised a PDA that could do all sorts of wonderful things, including recognising your handwriting? When it was finally shipped, the Newton proved to be too bulky and heavy. Worse, its most important feature, the handwriting recognition, did not work properly. The product underperformed and was finally withdrawn from the market in 1998. In hindsight, Apple was overly ambitious with its Newton plans. The company launched a product that tried to do too much at once, and failed.

The Steps towards a Minimal Marketable Product

To create a lean, minimal product, limit the target group and “build a product for the few, not the many,” as Steve Blank recommends in his book The Four Steps to the Epiphany. For instance, if you use personas to describe members of your target group, consider the impact of removing a persona. Would the product still sell? If yes, reduce the target group by dropping the persona. Once you have done a great job for your early customers, you’re in a position to build on the initial success with a new, incremental release that attracts new customers.

Second, understand your product’s value proposition and only select the features that are essential to address the needs of the target group. Have the courage and discipline to discard all others for now. Selecting the minimal set of features does not mean creating a bland, boring or simplistic product. It means focusing on those properties that are essential for the product success. If you work with user stories, for instance, review each story or epic, and ask yourself if the product can be shipped with out it. If yes, exclude the story. As the French writer and poet Antoine de Saint-Exupery put it:

“Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away.”

You can learn more about minimal marketable products by attending my Agile Product Planning training course. You can also find a more detailed discussion of the concept in my book “Agile Product Management with Scrum“.

A Sample Vision Board

Towards the end of 2012, I was exploring the idea of creating a software-based version of my Product Canvas tool that integrates seamlessly with JIRA and GreenHopper. To get started, I created the Vision Board shown below.


The Vision Board captures my assumptions about the users and the customers of the new tool, the needs the product should address, the key product features, and the value the product should create for my own business, Pichler Consulting. (I explain the sections of the board in more detail below.)

As you may have noticed, I have kept the information on the board concise and coarse-grained. I did not, for instance, write personas and user stories, or create a design sketch. There are two reasons for this: First, I did not know enough about the users and customers at the outset to write personas and to describe the product in more detail. Second, I find that more information is best captured by other tools: the Product Canvas or the product backlog, and the Business Model Canvas.

The board proved very valuable for me: It helped me think through my idea, and it allowed me to share my thoughts with my team, and with our development partner. Additionally, the vision board helped me investigate the greatest risks by testing my assumptions, as I explain below. I now use the Vision Board for any new idea be it writing a new book, creating a new brochure, or updating a training course, and I help my clients apply the board.

The Vision Board Explained

The Vision Board is the simplest thing that could possible work to capture the vision and the product strategy. It uses five sections as shown in the following diagram and explained below. You can download the template from the tools section of my website or by simply clicking on the picture below.


Vision is a concise summary of your idea that describes your intention and motivation. I also find it helpful to limit the vision statement to two sentences. You can find out more about formulating an effective vision in my post 8 Tips for Creating A Compelling Product Vision.

Target Group describes the market or market segment you want to address. You should state who the product is likely to benefit, who its users and its customers are.

Needs describes the product’s value proposition: the problems and pain points the product removes, and the benefits or gains it creates for its users and customers. The section should make it clear why people will want to use and buy your product, and what the product’s value proposition is.

Product summarises the three to five features of your product that make it stand out and that are critical for its success. These are likely to correlate to its unique selling proposition, and they should address the needs identified.

Depending on your product, the features may relate to functional properties (“mobile data access”), the design and the user experience (“cool, slick design that supports the brand and appeals to the target group”), or the technologies (“4G provided”).

Don’t make the mistake of listing lots of features. Stick to a maximum of five. Capture the product details at a later stage in your Product Canvas or product backlog.

Value explains why it’s worthwhile for your company to invest in the product. The section states the desired business benefits, for instance, increase revenue, enter a new market, reduce cost, develop the brand, or acquire valuable knowledge. The latter can be just as valuable as the former: When Toyota shipped the Prius in 1997, for instance, the car was not earning any money. But it immediately developed its brand (“green car company”), and had gained an advantage in hybrid technology.

There are, of course, other tools available that help you capture your ideas including Ash Maurya’s Lean Canvas and Alexander Osterwalder’s Business Model Canvas. I may be biased but I really like the simplicity of the Vision Board: I find it always beneficial to consider the target group, needs, key features and business goals when exploring an idea. Filling in all the boxes on the Lean and the Business Model Canvas is often but not always helpful. But you can happily use the Vision Board as a stepping stone towards creating he Lean or the Business Model Canvas (as I explain in more detail below).

Research and Validation with the Vision Board

The Vision Board is not only a thinking and communications tool, it also allows you to test your assumptions, and capture the newly gained insights. To get started, I find it helpful to identify the greatest risk or biggest uncertainty on the board. This creates focus, and it enforces a fail-fast: figuring out quickly what works and what doesn’t, which assumptions hold true, and which don’t.

When I was working on my digital canvas idea, for instance, the greatest risk was initially misunderstanding the user needs, and potentially building a product that does not provide much value. I consequently decided to test my user needs assumptions before exploring further what features the tool should provide, or how the product should be implemented. I hence started carrying out a series of problem interviews, structured conversation with a prospect to understand the individual’s problems and goals without referring to the solution, and engaged in a few direct observation sessions.

These measures helped me understand the target group better, and assess how much value a product canvas app with JIRA integration would provide. It also made me update and change the board to reflect my latest thinking, as the following picture shows:

I suggest you follow a similar approach when you work with the vision board: Identify your biggest risk, and attack this risk first. Don’t be afraid to fail: Early failure saves you time and money.


You can find out more about creating a product strategy with the Product Vision Board by reading my post 10 Tips for Creating an Agile Product Strategy with the Vision Board.

The Vision Board and the Business Model

I find that the strength of the Product Vision Board is its simplicity: It captures the core ideas necessary to create a new product — the customers, the problem, the solution, and the desired business benefits. But it does not detail how the business goals are achieved and it does not capture the business model including the competitors, the partners, the channels, the revenue sources, and the cost factors. Describing and testing your business model ideas is particularly important when you develop a brand-new product, when you want to make bigger changes to an existing product, for instance, to take it to a new market (segment).

To capture your business model ideas you can either complement the Vision Board with the Business Model Canvas or use its exerted version, the Product Vision Extended, which is shown below, inspired by the former, and is available for download at romanpichler.com/tools/vision-board/.


Physical or Electronic?

As its name suggests, the Product Vision Board is intended to be an analogue artefact that is kept on the office wall. A physical Board makes the vision and strategy visible and easily accessible. I find physical boards more fun and effective particularly when the strategy has not been validated yet: You can stand in front of it, review and discuss its contents, and identify risks and assumptions together as a team – assuming that you are collocated.

You can download the Vision Board template from my website and print it out on a large sheet of paper; or create your own board on the office wall or on a whiteboard using masking tape. Paper cards and adhesive notes are great to capture the board contents. This makes it easy to change the information and to support teamwork: Everybody can write a note or paper card to capture an idea and add it to the board.

Once the Vision Board has been validated and is stable, you can simply take a picture and post it on your wiki, or recreate it in an electronic tool.

Learn more

You can learn more about the Vision Board by attending my Agile Product Strategy training course. Please contact me if you want the course delivered on-site or as a virtual training.

This post was last updated on 10 October 2014.