Skip to main content

Bring back the fun! Four tips for the Product Owner...

...when the market isn't buying your product
"Is it OK to pass on market pressure to my team?"
This question came up in my last Certified Scrum Product Owner course ("Leading Innovation").  It seems that the company's development efforts, i.e. their products, had not been producing the desired effects in the marketplace. As a result, the finances were not looking so rosy, the investors were getting worried, budget cuts were in the air, and who knows what that means for people's jobs! The PO (recently converted project managers) wanted to put the teams under more pressure to perform, feeling it was both necessary and justified. Scrum says the teams are protected from undue influence, so we have a typical conflict between the classical approach and the Scrum approach.

So let's look at the this pressure, where it comes from, what to do about it, and how to best react to this situations.

Where is the pressure coming from?

Most of the time, the market doesn't care about us. We make something, nobody notices. So we compensate: with spam, advertising, marketing events, cold calls, etc. We create outward pressure, and customers should notice us and buy our products. If the customer is not buying, it is because we are not pushing hard enough. Why are we pushing? Because the market does not care.

So the pressure is not from the market, but from ourselves, because our lack of success will sooner or later cause us problems.

This does not mean the market does not exert any pressure. It can. It is called demand. It is the opposite of pushing. Pull is created when the market (or more precisely, people outside our company) genuinely want our product. Think people standing in line to buy the latest iPhone or see the latest blockbuster.

The first step is to realize that, unless the market is sucking product out of us faster than we can make it, the pressure is internal and entirely under our control. The trick therefore is to create pull for our products, so that there is a ready market.

How do we create pull?

In my eyes, the messages of Lean Startup from Eric Ries and Ash Maury give excellent guidance: find a problem that resonates with your (potential) customer base. Validate that it really is a problem in the eyes of your potential customers. Create a enough of solution so you can validate the solution with your potential customers. Validate it. Get your customers to tell you what it is really worth (by framing it against other existing solutions). If you get these things right, your customers will eat out of your hands! Note: This process may many iterations and require several changes to the initial product idea!

How should you lead your team?

To create products you need to be creative. Dan Pink explained the prerequisites: Automony, Mastery and Purpose. He also told us about the anti-pattern: things that cause to you to focus too much on the goal, like fear and financial incentives.

Most of us have had a "best project", where we did something great for our customers, our colleagues were helping us, as developers we were writing great code, our managers had our backs, etc. Remember that project? What would it be like if this project because like your best project. You can make it happen! (Hint: Many people using Scrum are experiencing their best project right now!). So make this project your best project for everybody on your team!

What to do when the market isn't buying your product

Your mission is to reduce risk. At the beginning of product development, Market Risk and Social Risk usually represent the biggest challenges. Are you building the right thing? Can your team work together to build the product? Budget Risk may also be an issue if your funds are limited. How can you get happy outcomes for your customers with less expenditures from your side?

As Product Owner, what can you do to minimize these risks when the market isn't buying your product? Four suggestions:
  1. Social Risk 1: Get any bad news out of the way. If there will be layoffs, get them done as quickly and as painlessly as possible. Once they are done, ensure that your team can continue long enough to show results.
  2. Social Risk 2: Bring back the fun! Create an environment where you and your team can have fun and serve a great purpose. Motivation is the accelerator for productivity. 
  3. Market Risk: Get you and your team close to your customers. Figure out where the shoe hurts. Offer them solutions. Validate your assumptions!
  4. Budget Risk: Say no. Don't build something unless you are really certain your customers need it and will value it!

Update: 21-Mai-2014 - after speaking with another startup who was having the same problem, I updated this article to emphasize the fun aspect!


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…