Note: This post and its companion were first published back in July 2014 after I was approached to provide a primer for startups. I think the content still holds true today, and as this site is changing direction for 2016, I thought it worth reposting here. – Col.
So you think you have a brilliant idea that will become a hugely successful product or service. Congratulations!
But how do you turn that idea into a well considered, structured game plan for how you will turn your concept into reality?
Traditionally, you’d do a bunch of stuff around market research, business plans, big project plans and a whole heap of things before you get anywhere near building the thing. But you’re an Agile startup right?
In these short posts, I’ll be referring to the great work of Roman Pichler. I consider Roman to be at the top of the tree when it comes to Agile Product Management specialists. His site has loads of detailed background and resources on the areas I will just skim over.
So how do you quickly get from a concept to an initial Product Backlog you can start working with? Here’s a high level of the first steps you probably want to take.
Step 1 – Understand your users. You should create personas for the different types of user your concept is aimed at. A persona is a fictitious person who represents as closely as possible a typical type of user of your product or service. Personas are important because they remind you that you are developing a product for people, not generic user types like “Author”, “Editor”, “Administrator”, “System User” etc. In most cases, you’ll have multiple personas to represent the different types of people your product is for. Make your personas visible in your team space to remind you everyday whom you are designing for. You don’t have to define loads of detail up front. Your personas will evolve as you learn more about them through user testing and other forms of feedback. Here’s a short definition from the Agile Alliance.
Step 2 – Develop the Product Vision. In short, you need to define who are your users, what of their needs are you going to address, a super high level view of the capabilities your product or service will provide to meet those user needs, and finally, what’s in it for you? You should also define a one sentence “vision statement” to encompass the whole concept. A vision statement for YouTube might be “A free online video hosting, sharing and streaming service funded by advertising”.
The Product Vision is important because it provides scope boundaries. We know that things move in and out of backlogs as we gather insights and inspiration.
We may define a Product Vision for a new car, and as we learn more about our users and our needs, an initial view that they want four seats may change. They may want six seats, because in our target market, people often travel with the whole family. But it’s still a car.
However, if our Product Owner explains that we need to provide 50 more seats, spread over two decks, that’s not a car any more. It’s a bus, and that doesn’t fit within the overall Product Vision.
That’s not a bad thing. It doesn’t mean we say “No, we’re building a car, so we won’t do that”. If our users really need a bus, we should reset the product vision and the steps that follow it. What we have discovered is that the car is not the right product to build.
The Product Vision is also very important to align understanding and expectations early from stakeholders. If you are going out to angel investors or other routes to seed funding, the PV and other artefacts will be absolutely vital to get your concept across concisely and professionally.
Roman Pichler’s Product Vision board is a fantastic resource that I have introduced to many teams. I wholeheartedly recommend it. Here’s a link to Roman’s site.
Once you have your Personas and Product Vision established, you have a solid foundation to work from. The PV is vitally important, but it lacks a critical dimension – time. In my next post, I’ll explain how you build on the Product Vision to move towards creating that Initial Product Backlog.