Author Archives: colsweetman

Agile product development for Startups (Part two) – Getting the initial Product Backlog

Agile startups

In the first part of this article, I provided some high level steps to get you from an idea to a user-centred Product Vision supported by personas.

In this final part, I’ll touch on one of the tools you can use to build on those artefacts and get an initial version of the Product Backlog.

Now, irrespective of how you are going to deliver this product or service, you will need two vital foundation elements to make sure you build the right thing, and build the thing in the right way.

The first is a business value model. What are the goals you are trying to achieve from this product or service? You should have a pretty good idea of these from the work you did in defining the Product Vision.

The second element is a list of the critical success factors that will determine if you have met those goals. In short, how are you going to measure if you are delivering the value you want, and how are you going to ensure that you are not wasting time and money over-engineering this to a point beyond what is actually needed. Agile organisations and teams are focused on delivering “just good enough, for now”, and no more.

A simplistic example might be to have a goal for the next car you are going to buy of “carrying my immediate family”. Initially, that might be just you and your partner. You only need two seats. But over time, your family may well grow, and you’ll need more seats. But you don’t need them right now.

The element of time, and the order in which the product or service may evolve over time is missing from the Product Vision. So we move to use the next Product definition tool in our toolbox – The Product Roadmap.

Again, I’ll refer you to the excellent resources made available by Roman Pichler. His Go Product Roadmap is an excellent tool, although of course other roadmap formats are available. The Go Product Roadmap was published late in 2013 by Roman, and I have recommended it to clients ever since.

I won’t go into the details of how to work with the roadmap, as Roman does an excellent job of that.

So I’ll skip forward in time to a point when you have completed your roadmap. I suggest you read through the presentation and explanatory material on Roman’s site before going further.

Now with your roadmap completed, you have versions of your product or service identified, each with a target completion date, goals, a high level list of features and the metrics you will use to track if you have met the goal for that version. It will look something like this

Product Roadmap Example

Now if you look at the features, goals and metrics across the different versions of the roadmap, and rotate them by 90 degrees, you might end up with something like this.

product backlog example

Let’s review what we expect to see in a Product Backlog, at a very basic level.

1.A Prioritised list of features.
2. Each feature should have an associated business value that aligns with
the overall business value model.
3.Each feature should have measurable success factors associated with it to
ensure we deliver to the right levels of quality – “Just good enough for
now, and no more”.

You have created a very high level Product Backlog!

Going through the steps in part one and two of this article will give you a simple framework to get you to this initial Product Backlog. It can be considered the Launchpad for the project.

Be aware though, that there will be a lot more work that will be done on reviewing and refining the backlog throughout the life of your project to make this brilliant idea into a successful product or service.

I wish you all the luck in the world.

Agile product development for Startups – Part one – First steps

Agile Product Development

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.