Skip to content

Are you a Bob Ross or a Rembrandt?

Coming up with a metaphorical question like this does require good explanation… And I will. Let me describe two cases.

Case one, develop according to Scrum

In the first case, you are running your development according to scrum. As a product owner you have your end goal clearly defined. You chop up your end goal functionality in small pieces, so you have a complete set of stories for the product available. These stories are fed batch by batch to your development team.

You clearly explain for every story what the result should be and why this is needed. This way you build your product in small incremental steps. Every sprint your product is growing and you are getting closer to your envisioned end result. Also, you have your stories prioritized so the important parts are build first. Sounds like the way it should… right?

Case two, develop according to Scrum

In the second case, as a product owner you run your development according to scrum. You have your end goal clearly defined and only a set of stories available to cover the next two sprints. You clearly communicate with every story what the result should be and why that piece of functionality is needed and how it fits in your envisioned end goal. After every sprint you evaluate the result, learn from the result and start to extend your story-set till you again have the next two sprints covered. This way you are defining your product as you go, while you still keep the intended end goal clearly insight. Anything you learn can be directly translated into the sprint without throwing away all the preparation work that you have done. Sounds also like the way it should.. right?

Two ways to paint your product

PBS Remix-Happy PainterCase one I see happening most of the time. And I understand that. It gives a clear framework and it provides management tangible result of the work of a Product Owner, even before development is started. In the end you need some proof that you are doing your job when you are in classic organizations. This way you can always show that it is not you if development fails somehow.

rembrandtIn second case you are lacking that “work proof” and you have to rely on “results proof”. For that you need to have the trust of the management. But the benefit of this way of working is that you learn while you are going forward without wasting any work that was done ahead of development. So less waste, more control, and more chance of hitting your goal.

Any new product is a journey into the unknown. Sure, you see an opportunity in the market, and sure, you have an idea on how to fulfil that opportunity. But everything is based upon interpretation, some vague market research on a focus group and gut feeling…

In the second case you can go back to your focus group, show the results of your sprint and take the feedback directly into stories for the next sprint without feeling the pain of throwing away work.

But as a Product Owner you need to be really close to your team in the second case. Observe every element during the sprint, be sharp in the sprint demo and directly understand the implications of every piece of functionality created.

So are you an artist?

Case one is painting by numbers.. The Bob Ross scenario. As a product owner you define the parts that the development team needs to color in fully upfront. Nice result for the people that are not capable of painting. You will not learn and you get the predicted product, but no guarantee on the predicted market result.

Case two makes you an artist. It is the Rembrandt scenario. You play with your lines, interact with your market and your team and learn from every stroke you make, discover elements you did not plan on. You are continues innovating and far better chance on achieving your desired market result.

I believe that the Product Owner needs to be a Rembrandt.

Ps: Special thanks to Bente Diemer who came up with the painter metaphor while doing research for UX in Scrum.

Reduced added value of consecutive releases

As also was posted on the Scrumalliance

A item about ever-reducing value of consecutive releases was lingering in my head, but it did not fully come out till I read this. It is a story about Rajen Sheth launching gmail in the enterprise space. He describes how he dealt with road mapping. Road mapping is one of the biggest pains for an Agile mind, since it forces you to plot an exact time line for releasing functionality over at least a year.

And anyone who learned about Agile, Scrum, or Lean start-up knows you are a fool if you try to do this. But the big problem is that the C-level boys and girls, for some reason, want it.

He correctly states that you should let them buy into the vision you have for a market, and show them how that vision is translated to functionality in the upcoming release. Also, all the features he stumbled into during conversations with customers and prospects were nicely identified and ranked. But then he made a mistake that may not hurt a company with unlimited resources but for sure can hurt your company (assuming your resources are limited).

He divided the most-wanted features into releases like:

  • Current quarter
  • Next quarter
  • Next 12 months (e.g., second half 2013)
  • Future (e.g., 2014   and beyond)

The problem of this approach is value.

Reducing value

Which items in general make it into the first current quarter? Exactly, the ones with the highest value. So automatically the important, hot, promising items that have just a little less value go into the “next quarter” release. If you talk to enough customers and prospects and have a creative mind and limited resources, your next quarter release is loaded before you have made your current quarter release. This is exactly how this terror thing called a road map got started!

So the major consequence of this approach is the reduced value of the next release, and the next, and the next, and the next . . . ending in only lame tweaks of existing features.

I would like to suggest (I am mild here since Rajen does have a kind of Guru status) to only commit to functionality in the current release. And make a ranking of the items for the next release without committing to it. Communicate your vision and goals continuously and deliver according to that vision. Keep it transparent and explain why items suddenly go on top.

If you have to commit to things past the current release, make sure you commit to the most limited number of items. Never have a fully planned release before you’ve even started working on a release. Ideally, you are committed content-wise no more than a few sprints ahead.

Reducing even more value!

Next to that, don’t let the customer’s wish list own your development. Product management is not about listening to your customer but about understanding your customer, so lists fed by current customers only will never bring you to new markets. This listening to the customer versus understanding your customer also is responsible for another source of reduced value. While you are building up value, your current customer will become more and more satisfied; as a result the items delivered on you feature list will become less and less valuable. You have saturated the needs of your customer. Actually, if you have reached that point it is time for a new vision, new segments, and new goals.

I know that it is very hard to put this in practice. It requires management and customers to buy into the product vision and goals and trust that you can deliver against it. And you have to deal with the C-level promises to this one special customer for that one special feature that is of no use to all your other customers. And that one is, most likely, the hardest. . . .

2nd pain.. new product

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.

Bugs bugs bugs bugs


It has been a while since I wrote my last item. So it seems like the right moment to start about the pain of product ownership. Over the years I have been in product management I have been confronted with a number of Big pains. The big three are Bugs, New architecture and New product.

As a product manager I consider adding some functionality to an existing product the easiest part of my job. You may need to overhaul something to get it done, but in general it is just adding the thing you want to add and make sure it fits GUI schema and workflow of the user. But if you are a real product manager these things come by nature.

Bugs cost

The first pain is really Bugs.. Your natural response on bugs is to fix them, and you should. But hold your horses. There is more. Bugs are the biggest enemy of your new functionality developments. Bugs cripple innovation. The cost of a bug exists out of:

  • sad customer experience
  • cost to fix
  • cost of missing the opportunity to build new functionality

And the last one is really the major one. It is my believe that fixing a bug is softening the pain of a customer, but new functionality can really take away the pain. So you always try to deliver new functionality. But, of course, there is always a balance. (did I already mentioned that I hate nuances..)


If the number of bugs is growing, and regression bugs start to appear, there is something more you need to do. You need to know about the quality factors in your production. Is your product being coded according to all the quality standards? Are there unit tests, are there automated tests and run all these tests with checkins and builds? You need to know..

And over time you will discover that building a sustainable product can only be done based upon the best development standards. Even while you are a product manager, you should want and demand these standards. There is no excuse for not creating unit tests and automated test cases. And manual testing is not adding quality to a product. Quality is something that is transferred from one version to a next version.

Manage your bugs

How do you manage your bugs… I prefer not to.. 🙂 In my current role we have solved it in the following way. We have made a historical estimation of average time per two weeks spend on bugs. This average is the reserved bug budget in the sprint. Next we have given this budget to the Customer Care Manager and lead engineer in second line support team. These two deliver every two week their priorities. These priorities fill in the bug budget. Of course the content is overlooked by Product management. This allows product management to focus more on moving ahead and pulling the product forward. But at the same time every sprints delivers a stable balance between fixes and new functionality. But the best thing of all.. the hard choices of which bug is fixed in the next sprint is made by the people closest to the user that feels the pain. As a product manager you should be really careful with increasing the bug budget.. in general there is no reason to do that. In fact, it should go down.

And for the one that wonders.. you should not fix every bug. There a loads of bugs that simply do not get through the cost-benefit equation. But that could be a subject on itself again.

Next blog will be on the second biggest pain of a product manager.

Scrum means business

Everything you hear about scrum will tell a story about better and faster software delivery, higher quality and more happy employees… But what does this mean for your business. Sure, quality is nice, faster delivery is good, and we all don’t mind working with motivated people. But from a business perspective you need more benefits.

Let’s invest

Software development is about investment. Building new functionality is an investment that needs to be paid back in sales. These investments are big. Imagine a modest 20 developers team building functionality during the course of half a year. Let’s take a simple approach to this case for BtoB environment. In many countries this means a 1 million USD investment. Doing this in a traditional waterfall way will have the following symptoms:

  1. Sales is very reluctant in selling during the development phase. History has proven that products are delivered late, so sales is careful.
  2. Tangible product only becomes visible close to the end of the development, and only then can be reviewed by customers.
  3. Finished product always require post release changes to make it really fit for the market.

The investment is invested as a single shot. You can aim once for your market and that shot has to be spot on. Any change requires additional development  investment after release to make it spot on.

Your investment according to scrum

Take the same scenario according to the scrum method. Developing based upon 2 weeks sprints, and based upon completed (manuals/tested/ training) functionality during these sprints. This will have the following symptoms:

  1. One month into the development of product the first functionality of the product can be demo-ed to customers, even a manual of the completed parts of the product can be shown.
  2. Feedback of customers can be fed back into development and adjust the development already after approx. 1 month into development.
  3. Due to the ability of showing tangible product, sales can start already after that first month
  4. Finished product has been widely exposed to customers and users, and is spot-on developed. Additional developments are extensions.

Product maturity

Let’s try to capture this. You could think of something that is called Product Maturity. Maturity is something that will grow as product changes are based upon exposure to users. The more a product is exposed and the more changes are resulting from that, the more mature the product becomes. Source of the change can be misalignment of product functionality but also evolution of users and markets (competition) or later discovered opportunities.  And, of course, a more matured product has a better chance on higher turnover.

Let’s try to capture this is some extremely simplified graphs (and even that is an understatement).


First the waterfall one. Maturity grows in steps and sales starts at the end of the first development step, so close to 6 months into the process. The graph above already shows 2 releases. Typically in waterfal these are many months apart. The second release is in general used to correct failures in market alignment and quality.

Next have a look at the scrum version:scrum

Needless to say that the scrum method will provide a quicker return on the investment made. My guess that this will be at least 30% faster (very pessimistic estimation).

But there are a number of other advantages with regards to the investment made:

  1. Adjust product very early in the process to the market
  2. Ability to cancel a project in a very early phase based upon realistic customer feedback
  3. Respond during the development process to competition

Using waterfall you are always at least a year behind on your competition. This is valid even for small functional elements, since waterfall tend to result in one or maximum 2 releases a year. So you could say that you need Scrum to get agility in your business.

I know that in real live there are many variables that will change these graph, but there will be no situation where investments are earned back faster using waterfal. But if we simplify one situation, we also have to simplify the other.

Scrum starts at Product management

In the past few years I have been implementing scrum from scratch twice. This is the reason why I have not been writing too much lately. Too busy getting scrum going. Both times it turned out that there was not much resistance or big hurdles. Both times the teams had to turn around from vague waterfall approach.

This makes me wonder. Why are there no major battles? Until tonight I could not really give an answer to that. But at a scrum meeting I had the pleasure to talk with an development manager of a big insurance company explaining me his difficulties of implementing Scrum from out of development while product managers did not buy in. That was pain… While I am thinking about tuning after 5 sprints, he was struggling to get requirements discussed a year after introduction. He is a long way from his hyper performing team goal. And I am not even taking the culture of the Insurance business in account here.

So, I guess, the difference is the support or even drive from out of Product Management. Of course without sitting on the chair of the Development Manager  or Scrum Master. But why does that make such a difference? I think you have to look at the traditional role of the Product Manager to find the answer.

Don’t be evil…

For the average development department the product manager is evil. It is the guy that want the impossible functional, in a unrealistic timeframe. And since everything is put into a 100 page requirements doc, these cannot be discussed  anymore. It has been signed off, we can’t change it!

When your Product Manager turns into a product owner the role changes completely. Let’s start at the requirements. No more 100 pages of requirements, but stories. And since stories are invitations to discussion suddenly the requirements are things an entire team can start thinking about. You have a platform that involves the developers in creating a solution. They are not building the solution, they are now part of coming up with a solution.

Another element is the fact that you deliver functionality every sprint. Due to the fact that each sprint you want to build value, every sprint demo the developers will show things that are relevant an tangible. It suddenly makes clear that what these guys are doing makes sense, that they are actually building value.

No battle

There is no developer on this world that does not want this. If Product Management supports transition to Scrum, you have won halve of the battle.. or maybe there was no battle at all, you just made a transition. If a team is confronted with an involved Product Owner, working as a developer becomes fun.

I am sure that the role of Product Owner can make the difference in making your transition a success. Also I believe that you rather should be a Product Owner then a Product manager. Since it gives you full control on creating successful products, instead of successful requirement documents.

Un-acceptance Criteria


Like many Product Owners I struggle with writing stories, or to be more accurate, I struggle with the acceptance criteria of stories. In an earlier post I tried to make a point of not writing great stories. Perfect stories will reduce the number of questions, and questions are the perfect measure to determine if someone understands what you want (you then achieve documentation over communication).  Nevertheless, I started digging into the acceptance criteria again. Just to understand what others are saying about it.

Adding no information

The story example above was the first one I found.  And apparently they did read my previous posts, since it hold loads of errors. J The three acceptance criteria listed are really not acceptance criteria from my point of view. The first one, providing a valid id and password is a 100% redundant sentence. It adds no information at all to the original story, and actually covers the happy scenario of this story. The second and third are equally redundant. Yes, we now know we have to create an error, but should case 2 and case 3 provide an identical error? Or should case to make a difference between wrong id and a wrong password? This would typically be covered in a separate story.

So, on the above Story the acceptance criteria example only results in a product owner that looks like a fool. And it is very easy to look like a fool in front of developers.

Hidden epics

Another example can be found at

As a user of the library catalogue, I want advanced search options on the front page so that I can quickly and easily refine my search.

The acceptance criteria are written in simple language that the customer would use, just like the user story. For the example above, the acceptance criteria could include:

  • I can limit the search by format/type.
  • I can delineate the search by date range.
  • I can limit the search to publisher information such as title, author, subject, place, publisher and call number.
  • I can restrict the search to a particular website/catalogue, collection.
  • I can find advanced search options – advanced search options are carried through as filters to search results page.
  • I can filter by availability.

Here the acceptance criteria are abused to add more sub-functionality to the story. So this story actually contains 7 stories. And the top story should be an epic. Each of the above should be split out towards separate stories.

These are the kind of stories that end up with massive number of storypoints estimations.  However nice it seems, the above is really a bad example of what a story should be.

Finding a way with waterfall habits

A third nice example can be found at:

Acceptance Criteria are defined as scenarios:

As an Account Holder
I want to withdraw cash from an ATM
o that I can get money when the bank is closed

Scenario 1: Account has sufficient funds
Given the account balance is \$100
And the card is valid
And the machine contains enough money

When the Account Holder requests \$20
Then the ATM should dispense \$20
And the account balance should be \$80
 And the card should be returned

This is an interesting approach. Reading the story above it tells the developers that they should create an ATM that withdraws the amounts it dispenses from the account balance. These kind of stories are painful left overs of the waterfall age. Those were the days that ‘if it was not written, you are not building it’. As a result you ended up with thousands of absurd scenario’s covering variations of the above. While I believe that taking the scenario approach is right, don’t write out scenarios like the reader is a mental disturbed. Also, acceptance criteria should fit on the back of the sticky note. A final argument in this is that a tester’s job is not to test functionality against scenario’s you write for them.


Concluding I see a number of things in the acceptance criteria:

  1. Totally useless information that makes you look like a fool
  2. Test cases that tells your, very well educated, tester how to do his work.
  3. Sub stories, that should be covered as a separate story
  4. Waterfall leftovers aka cover your ass descriptions. Only there to protect you from people blaming you.

Acceptance criteria can be useful. But I am sure that they are not, if they can be categorized as one of the above 4 categories . Very often you see that they are created as a kind of habit coming from the waterfall age and the misbelieve that you actually can develop functionality based upon a single line and sensible people in your team.

Scrum is based upon a vocal handover of stories. So in the sprint planning and in estimation sessions, the product owner ‘presents’ the stories. This is an essential part of scrum, since it is the only way to convey understanding. Doing this completely removes the need for ice waterfall age kind of specifications.

I know I cannot criticize others without giving my own view on it. Using one of the above used examples:

As a user of the library catalogue, I want advanced search options, using an including or excluding date range, on the front page so that I can quickly and easily refine my search

Acceptance criteria.:

  • Dates manually entered is according to the international ISO date format (ISO 8601)
  • Dates entered via date picker tool should also be displayed according to the official format

No idea what application this would be for, but I do like to hear of my readers if you can come up with more acceptance criteria that make sense. So fire away!

Agile for farmers!

Agile development has proven itself already as a great way of developing software. It is based on communication and pulls the different stakeholders into the project. This is the opposite of the past where we treated development projects as a blackbox, and pushed the stakeholders as far away as possible to avoid change.

Apart the changes in development departments there are a few more areas of discipline that need to undergo change in order to get the maximum out of Agile. I think there is a massive unrecognized challenge for Account Management. Many things are put on the plate of the Product Owner, which actually are activities for Account Manager. I can say that for farmers there is a great opportunity.

I believe that Account management need to manage the engagement of the customer in the development process. There are several things that customers need to do and understand. The list below is what I have experienced. Now my experience is mainly based upon developing products for the B-to-B market with high level of customer involvement.

  • The customer needs to invest time during the project to take part in demo’s
  • The customer needs to allow users to review and provide freely feedback (uncensored feedback)
  • The customer needs to allow communication between their users and the Product Owner
  • The customer needs to understand the concept of development in iterations, concept of backlog and the priorities principle
  • The customer should be able to agree upon functional business goals, not on detailed unrealistic requirements
  • The customer should understand their level of control on created functionality (Here there is a huge difference between product companies and projects, but for both it is valid to say that the customer should not be in the product owner seat)

All in all, this comes across as a great opportunity for Account Management to increase their value and improve the success rate of projects, especially since the success of these development projects depend completely on the engagement of the customer.

Think it makes sense to take our time to educate Account management and Sales.

Securing a design in an Agile process

Over the last few years I have ran several times into the situation where people inside or outside the team suggest to create a style guide for the graphical design of the application. And I have responded to that question in different ways over time.

First time, approximately 7 years ago, I got confronted with this question, I looked at the problem and believed that a style guide could be a solution to get rid of the detail differences in the implementation of new functionality. So, having that believe, we made a guide covering each type of GUI component and how the look and feel should be for the application. Great piece of work with two major results:

  1. Within 3 months after completion we were confronted with new GUI components that were not covered in the guide.. now what?
  2. Within a few months no one looked at the document anymore

Conclusion is that the work spent was wasted and the original problem still existed.

The second time I was confronted with this situation I did not wanted to run into the pitfalls of the first time. I understood that evolution of the application will go faster than the evolution of a document. We made a number of concept screens. More or less a number of mood boards providing more an atmosphere the screens had to comply too. Nice idea and it dealt with the issues I ran into before. But unfortunally, every developer had its own idea on how it looked and felt like the mood boards. As a product owner I also gave my opinion and had the final saying on what was released. But I am not a graphical designer, so a little more successful, but still a huge opportunity for improvement.

And, of course, I did get confronted with this issue again. And I decided to rely on people, instead of artefacts. Instead of creating document, mood boards or examples, we decided to pull in the graphical designer. We decided to, as far as that was possible, make the graphical designer part of the team. This way, an esthetical eye was constantly watching us while we created functionality. Making sure things looked like they should, with the highest level of consistency.

Now this graphical designer was not a full time member of the team, but we did made sure he felt like he was part of the team. That each team member knew him and had access to him, he was also part of the skype group so it was easy to quickly share a screen with him and solicit feedback on what was created. Needless to say that this worked as a charm. Of course the vulnerability of this solution lays in what to do when people are absent or choose to leave a company. But however much managers dislike it.. companies are made out of people, and have to be special people if you want to achieve special things.

As a product owner your live revolves around ‘As a’


It is the start of almost every story you deliver to your team. A story that is build up out of, most of the time, a single sentence. The single sentence that forces the reader to impersonate themselves into the role of a user, administrator or any other person that uses the application. The power of those two words in enormous.

Three letters puts the reader of the story instantly in the ‘imagine’ mode. So a developer is forced to think as a user or administrator when he/she pick up the story. It sound trivial, but it is the essence of successful development. Everybody should have the customer or user in mind. Those two words are forcing developers to do this

So it is not only the Story you write that starts with these 2 magical words. It is far more. You are constantly utilizing the imagination of yourself and your stakeholders to drive the product further.

You, the Product Owner, you should be able to view your product as a user. You should be able to view your product as a customer and you should be able to view your product as a Developer. It is the core attitude and talent you need as a product owner. The ability to look at you product from different angles and see the benefits and hurdles for the different stakeholders.