Skip to content

2nd pain.. new product

September 9, 2013

The 2nd pain of a product owner

Time for the second big pain of the product owner.. Starting a new product. As I stated in my previous post, the easiest thing of a PO is adding new functionality to an existing product. An existing product gives you a framework to work within.


This framework exists of the market, the user (and its needs) and the product ( a defined GUI structure, the technology stack, the database, etc.)

Everything is already there. All you and your team need to do is to extrapolate into a certain direction. You define the direction, but your team can easily follow, because the base you are coming from is know. Also, for the users it should be just a matter of extrapolating on the thing they used to do already. And of all the types of changes you can think of, extrapolating is the easiest.


But starting a new product takes away all or a big part of this framework. There are a massive number of things unclear. Not only the question of adoption is unclear. Typically that is the big thing of worry, but there are also loads other things unclear. Just sticking to the product many decisions have to be made. Gui design, application architecture, technology choices, etc. All these things are questions that need an answer.

Now you can spend months, or even years specing out each of these elements. Doing that is the perfect way of missing your window of opportunity for your new product. Take a different spin. Why do we like scrum? Well, for me, it is the perfect way to hit a target. A product has a market goal. Taking an “aim once” approach requires me to be a perfect archer. Scrum allows me to control the arrow in flight, so even if the target starts moving I can still hit it.

That is where most of us see the benefit of scrum, the commercial side. And of course, in the end that is what matters. But apply the same principle on technology choices, GUI design and all other elements.


I believe that you can also use scrum to do a fair part of the technology discovery and design. Create the most simple story (hardly any commercial value) that does forces the team to make choices on the area’s that are undefined. This will get the developers hands-on and understand the pains of certain choices. If it turns out that a certain choice was wrong, a single sprint was lost (not wasted since you have learned). Make sure that before you start these stories, it is clear that the goal is evaluate and learn from the uncertain elements in the system.

Another benefit of this is that these simple stories also will give you a starting point for your real user value stories. Because a new product in general has groundwork that needs to be there before the first stories that can be demo-ed are done.

I know.. this is a lean approach.


From → Uncategorized

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: