Monthly Archives: January 2013

The Case Against The Traditional Business Case

By Shardul Mehta

Note: This post was originally published on Shardul’s Blog, the Street Smart Product Manager. It is reprinted here with permission. Shardul also published a follow up post to this one on his blog. You can find that post here.


I have a confession to share.

I don’t like business cases.

At least, I don’t like the traditional way I’ve been taught to prepare a business case. Why do we prepare business cases? Convention. The conventional approach to pursuing a new product idea in an organization is to first prepare a business case. This is what we’ve always been told. It’s what we’re taught in business school, and there are even competitions organized around it. And it’s been reinforced every time we need IT and implementation resources for a new idea: the only way I could get those resources was by having a business case. And this usually meant filling out a cumbersome form or writing a big document.

Now, I’ve written many business cases in my career. Some good, some excellent, many bad ones. Over the years, I’ve gotten pretty good at it. But every time I did it, I hated it.

There are many reasons, but since this is a blog post and not a book, I’ll share three:

1. I always felt it was a time consuming exercise in guesswork. For example, I’d be asked to estimate (guestimate?) market size and put multi-year financial projections. This, I felt, was an exercise in future prediction, and we humans aren’t always the best at predicting the future. I’m certainly not.


2. No one reads it. People are busy. They don’t have time. Most want the elevator pitch. I can’t count how many pitches I’ve been in where the execs flip to the end or simply ask you for the bottom line: what’s the opportunity, how much do you need, why do you need it, when do we see return. 60 seconds. Go.

This means a business case is nothing more than a 20, 50, or 100-page paperweight. Steven Blank famously called a business plan “a document investors make you write that they don’t read.” The same could be said for the traditional business case:

“A business case is a document executives make you write that they don’t read.”

3. Selling the business case is hard. This is especially true in larger organizations. Lots of opinions. Lots of approvals. Competing agendas. And back to #1, what you’re doing is trying to sell a non-validated promise. This means you’re asking the executives – the ones entrusted with the financial well-being of the company – to shift resources currently assigned, or approve a lot of money, or both, for something that has a high degree of uncertainty.

A related challenge is ensuring internal stakeholder alignment and support. It’s important to capture and address stakeholder concerns to ensure continued buy-in, and that everyone is on the same page. This is time consuming. Part of that has to do with the realities of coordinating schedules. But also I’ve found this experience to be very ad hoc and messy. There must be a better way.

Is there a better way?

Now, maybe the way I’ve gone about creating and selling my business cases has been wrong. Maybe my situation is unique. Maybe others don’t find this process so wasteful. Maybe they’re more brilliant than I am in creating awesome business cases that always get approved. Maybe they work in organizations that have streamlined the process to pursue a new product idea.

Maybe I could test that hypothesis.

So I did. I set about to find out what other product management folks’ experiences have been with the traditional business case process.

I reached out to 40 product management professionals. Over a three week period, I spoke with 24 of them. All had experienced preparing and selling a business case for a new product idea. They had an average of 7 years PM experience, and had titles ranging from Product Manager to VP of Product Management.

They worked across the country, in companies across a range of industries, as big as tens of thousands of employees to smaller ones with 50-100.



My Findings

Getting buy-in was rated as the #1 problem by every person except one. And that person rated it as a very close #2.

75% of them validated that maintaining stakeholder support and alignment is important, but a challenge. Only 3 out of 8 pursed doing this in any kind of systematic manner. Most agreed it was pretty ad hoc.

So this clearly validated the third problem I listed above. What about the other two?

Now comes the interesting part. Though creating the business case was acknowledged as time consuming (validating that piece of my first problem), most did not feel it was a major pain point. Not entirely surprising, because like any self-respecting product manager, they all felt confident in their ability to put together a solid business case. Yet, when I probed deeper into their feelings about the actual act of preparing a business case, I uncovered an outpouring of vitriolic frustration. Here’s what some of them had to say:

  • “It’s a necessary evil. But it’s a wasteful process.”
  • “It’s a joke.”
  • “It’s just a lifeless Powerpoint deck.”
  • “It’s a manager fighting with an Excel spreadsheet for a month.”
  • “I’m forced to project revenues out of thin air. Putting revenue projections is a nonsensical exercise.”
  • “Financial analysis – it’s really just pretend.”

Note the words being used: “lifeless”, “nonsensical”, “pretend”, “joke”, “evil”.

And my favorite comment:

“You are describing my life!”


I feel safe to say this feedback clearly validated my entire hypothesis.


So what’s the solution? This is not so easy to answer. It seems to me we need a different way to pursue new product opportunities within our organizations. One that will allow us to create more validated business cases, and provide us with tools and resources needed to obtain that validation. One that will enable us to more systematically build and maintain critical internal support. And one that allows us to spend more time developing and testing product than writing paperweights, while also providing an economical and efficient means to communicate progress for continued engagement, feedback and buy-in.

What has your experience been with business cases? How have you pursued a new product idea in your organization? Please share your frustrations or joys in the comments below or let’s chat!


Tweet this: The Case Against the Traditional Business Case #prodmgmt #innovation

Why don’t Product Managers go to Club?

It’s that time of year when companies are having their annual sales kickoffs and also announcing which members of the sales force sold enough in 2012 to qualify them to go to Sales Club.

If you don’t know what “Sales Club” is, you’re definitely not in sales :-).  Sales Club is a reward given to top producing salespeople. It is usually an all expense paid trip to a high end vacation resort in some place like Hawaii, the Caribbean, Mexico,  Tahiti, Bali etc. You get the picture.

While this is a great reward for salespeople, what about everyone else who also significantly helped the company achieve it’s goals?  The  top sales people didn’t achieve those numbers on their own did they?

Let me refer you to my Devil’s Dictionary definition of “Sales Club”.

Sales Club: n. A disincentive program for non-sales employees who make significant contributions but aren’t likewise rewarded with a trip to an exotic location.

Yes, I’m griping a bit here, but why not?   And don’t tell me because we’re not in Sales.

Product Managers (and Product Marketers) provide key strategic and tactical help to Sales. We are often called in by Sales, when they need some “big guns” to talk  product roadmap or strategy with the prospect to convince them to sign the deal.

We travel (often on short notice) to customer sites to support proofs of concepts or defuse tricky customer situations.

We focus on both the short term tactical activities — ensuring the funnel is primed for sales — as well as longer term strategic ones — ensuring product, positioning and messaging are aligned with market needs.

I could go on, but I’ll stop here and ask the following:

  1. Do any of you Product Managers or Product Marketers get invited to Club?
  2. If so, what is the criteria used to qualify?
  3. Who decided that PMs and PMMs should go and why? i.e. it had to be a conscious decision made by some executive at your company?

You can leave your responses in the comments.



Tweet this: Why don’t Product Managers go to Club? #prodmgmt #sales

Estimation Tips to Create Realistic Product Roadmaps

by Steve Johnson, Under 10 Consulting

Did you ever have this conversation growing up?

You: “When’s dinner gonna be ready?”

Mom: “Seven-ish.”

You: “Uh, can you be more specific?”

Mom: “It’ll be ready when it’s ready!”

Estimating is perhaps the biggest issue facing product managers regarding product and portfolio roadmaps. Obviously you want to get an estimate before anyone spends too much time designing a solution but you can’t really get a valid estimate without some level of design.

Here’s the big trick: guess.

A guess is good enough for this level of planning. For roadmapping you don’t need a person-hour estimate; you just need an idea of whether it’s a month or a year, tiny or huge. Experienced teams find they can quickly and easily estimate roadmap items by fiscal quarters. This item will take one quarter; that one will take three quarters.

Unfortunately, a lot of product leaders and company leaders expect precision in these estimates much too soon. Postpone this level of detail until your team has a chance to examine the idea further and get more specific in terms of effort.

And remember: an estimate is a guess, not a commitment. Assure your teams that these are sizing estimates, not date commitments. If they said it might take a quarter, assure them that you are not committing them to delivering it this quarter. Estimates are “no-sooner-than dates.” An item estimated at two quarters will be available no-sooner-than two quarters from when we begin.

Estimating relative effort is the key

Rather than estimating in months and quarters, most teams are more comfortable—and more accurate—when estimating size: this is bigger than that. A little bigger or a lot bigger.

I like assigning a relative number to estimates so that you can compare dissimilar things. But be careful with numbers. Before you know it, some fool (maybe you!) will try to equate these effort numbers with person-weeks or –months, and create an atmosphere of distrust between the development team and the rest of the company.

Your teams probably have history estimating user stories; they can use the same techniques with epics and roadmap items.

Agile teams generally use the Fibonacci numbering scheme for estimating. Fibonacci numbering is the sum of the prior two numbers in the sequence, like this:

1, 2, 3, 5, 8, 13, 21, 34, 55

Estimating using a Fibonacci sequence means that each estimate level is as big as the prior two levels combined.

But Fibonacci is not the only way to estimate. It’s fairly common for agile teams to use “shirt sizes” for the first, rough estimation. This feature is small; that feature is large. You can assign numbers with shirt sizes using a scheme like this:

Tiny: 1, Small: 2, Medium: 4, Large: 8, Huge: 16

This “Doubles” method shows that each level of effort is twice as large as the prior one. So “small” is twice as big as “tiny;” “medium” is twice as big as “small.” Another way of thinking about it is you can do two “tiny” things for the same effort as one “small” thing.

For a more dramatic escalation curve, some teams prefer the “Squares” method:

12: 1, 22: 4, 32: 9, 42: 16, 52: 25.

Here, “small” is four times bigger than “tiny” and “medium” is more than twice as big as “small”.

Comparing three schemes

Here’s the thing: The actual values don’t really matter as much as the relative values. It turns out that people cannot accurately estimate time but they can estimate relative effort. It’s difficult to say “this will take 2 months” but it’s easy to say “this is larger than that.”

Estimating is a team effort

So bring your team together, discuss the various items you have planned for the roadmap, and get their estimates.

image sizing estimates

It’s been proven that team estimates are more accurate than an estimate from one person. Three people on a team is good; five is even better. When there’s a discrepancy, you’ll want to get those who estimated highest and lowest to explain their reasoning. Maybe they’ve seen something or assumed something that the others haven’t. Explaining this point of view may cause the team to re-estimate with the new assumptions.

This approach for assessing the effort for a roadmap item, a user story, or an epic is known as “planning poker.” Read more about this method of estimating at from Mountain Goat Software.

One last tip: Before you start an estimating exercise, I recommend you begin with a benchmark. Choose an item or two that your team has already completed—one that you know the time and effort it really took—and then compare new items against that benchmark.

So whatever your method—time in quarters or relative effort—you’ll want an estimate of size for each roadmap item. It will help you ensure that you’re not over-committing your team.


Tweet this: Estimation Tips to Create Realistic Product Roadmaps #prodmgmt #agile #roadmaps

About the author

Steve Johnson is a widely recognized speaker and story teller within the technology product management community. As founder of Under 10 Consulting, he helps product teams implement strategic product management in an agile world. Sign up for his newsletter and weekly inspirations.

Do you really understand the true benefits your product delivers?

By Saeed Khan

At the most fundamental level, virtually everything we do is driven by some very fundamental needs: we want to remove what pains us or increase what makes us happy.

As Product Managers, part of our job is to try to understand the reasons why people would buy and use our products (or services).

In most cases we think we know — e.g. it increases their productivity or saves them money or let’s them do something they couldn’t do before — but often its much more fundamental or specific than that.

Here are two recent examples that I came across that I want to share.

Case 1 — Increased productivity or avoiding difficult people?

A friend of mine  (a Product Marketing Manager) told me that she had gone out to visit customers to discuss her product and how those customers were using it. At one customer site, she started talking to some users about how much more productive they were by using her product.

The customer said they had created a detailed breakdown the benefits the product provided for an internal audit and shared it with her. The spreadsheet had the following columns:

  • Task #
  • Manual time spent
  • Time spent using <product>
  • Percent savings
  • Comments

There were dozens of rows in the sheet, each showing a task performed manually and automated via the software. Although the “Percent savings” column had a lot of values between 50% and 70%, some were as high as 90%! i.e. the product was significantly increasing productivity.

What caught her eye though were a number of Comments that said “Need to contact DBA”. Many of these steps had a VERY high “Percent savings” value. She asked the customer why they put those there.

The response?  Those steps required a DBA (Database Administrator) to configure, create or change something in the database. The customer also said getting DBAs to do what was needed was almost always difficult and time-consuming. A major reason they liked the product was that it eliminated the need to contact any DBAs.

“This is huge for us!” was a quote from the customer.

At subsequent customer meetings, if the issue was not raised, the PMM innocently asked about interactions with DBAs and quite often got a similar response.   Overall this was news to her, and without directly attacking DBAs, this nugget will become a key point in her product messaging.

Case 2 — Flexible reporting or time spent with family?

In another scenario, from early last year, a PM was talking to a customer (Albert) about a new release,  and in particular performance and usability improvements that had been made.  Albert was interested and agreed that those new capability were helpful, but wasn’t too excited about them.

The PM became concerned given that a lot of effort had gone into rewriting underlying code and aspects of the UI to make those changes, and users had been very vocal about the need for them. Somewhat perplexed, the PM asked Albert, why he didn’t appear that interested in those new capabilities. Albert responded that his role had recently changed to a more administrative and business focused role so he wasn’t going to be using the product hands on like he had previously.

“Fair enough” thought the PM, and then asked if there was anything he needed in his new role to help him with his duties.

Albert referenced some new reporting capabilities that had also been released and said those were what  he needed. The PM hadn’t spent much time talking about reporting as it seemed rather mundane and was basically a “catch up” feature to close a glaring product gap.

Albert’s company was in Pharmaceuticals and he had a number of monthly and quarterly reports he needed to provide to management for regulatory reporting and compliance.

Albert’s predecessor had been manually creating these reports and had warned Albert that he should expect to work late at the end of each month and quarter to get the reports completed on time.

“Tell your wife and kids not to expect you for dinner the last few days of every month.” was what his predecessor told him. It turns out the new reports provided most the raw data needed for the regulatory reports. There was still some manual labor needed, but collecting all the raw numbers was always the most time consuming part of the task.

The PM asked Albert what he would have done had the reports not been there? He said he would have found some other way to automate the data collection process, with either a home-grown system (not desirable) or from other vendors (of which there were a few discussions already happening).

The PM realized this was a big issue to promote and decided 3 things:

  • first, that the next release of the product would include reports specifically created to address Pharmaceutical needs
  • second, they had a new vertical market to start targeting and marketing to
  • they knew who to target as advocates and influencers during the buying process


I like both of these stories because they clearly illustrate that the drivers of the buyers or users of products are often much more personal and fundamental than we often believe. It’s difficult to get this level of detail from people. A lot of them aren’t willing to open up, and often, WE don’t engage in the right types of conversations or have the right relationships to find out.

But when we do find out, the results can be significant because we can connect with customers and prospects in ways that go far beyond the usual business rhetoric and meet strong and truly personal needs.


Tweet this: Do you really understand the true benefits your product delivers? #prodmgmt



Ramping Up a New Product – This is where you really Start to Sweat!

By Rivi Aspler

You have been working like hell for the past few months. You have been gathering requirements, prioritizing, defining, following up, getting everyone aligned, facing constraints and hence re-defining and re-prioritizing, managing trade-offs and hopefully closing down already developed requirements. Your product is ready to go. You are exhausted! But the hard work is just starting – getting the first customers to adopt and use your product.

endurance_1If you are working for a large company, you’re lucky; someone else is responsible for the ramp-up program. If you are working for a start-up or for a mid-size company, take a deep breath because as the saying goes: “when the going gets tough, the tough get going.”

A lot can be written on this topic,  but here are a few important items to remember:

On your side:

  • Create a (virtual) Ramp Up team - Create a committed virtual team specifically assigned to the project for a specific amount of time (e.g. 2 days per week for 4 months) to ramp-up your new product.
  • Specify clear and quantified targets – Have clear goals for the projects. e.g. “our aim is to get 5 customers up and running with the new product, grading it with a 7-8 satisfaction level, all in the next 4 months”. Without specific goals it’s impossible to know how successful the ramp-up is.
  • Remove obstacles from your ramp-up team’s way - Obstacles can be as mundane as  “I have no laptop for a demo” but obstacles can also be as serious as a mid-level manager that doesn’t allow a ramp-up team member that 2 days per week that were authorized by the CEO.
  • Get the ramp-up ‘A-Team’ talking with each other;  at least once a week –  Weekly synch meetings keep the project members aligned. Review last week’s activities and next week’s tasks, set clear goals and plans.
  • Make sure your ramp-up processes are start-up like – Agility in this case isn’t just a buzzword. Make sure your ramp-up team members can move fast, don’t have to write down everything and have only one person to report to.

On the customer side:

  • Include early adopters in you ramp-up program – Don’t waste time on late adopters or on customers that are high maintenance. You will have plenty of time for them after you have gained the required momentum.
  • Be honestMake sure your customers know that they are part of a ramp-up program – Customers expect more of a mature and field-proven product than an immature product. It’s likely  that you will experience problems (i.e. challenges) during the ramp-up program.
  • Get commitment from your customers’ senior management – An implementation of a new and young product requires patience. Having the customer’s CIO committed to the process (for example, opening a training day) increases the mid-level managers and day-to-day end users commitment to the process.
  • Have someone regularly visit the customer’s site, for the entire ramp-up period – Regular visits to the customer’s site are demanding but imperative.  There’s nothing better than observing the customer first-hand, discussing issues and getting to the heart of any problems.  It builds strong relationships and minimizes the chance that something will deteriorate to a level that jeopardises the ramp-up program.

And most important; schedule a vacation (for after the ramp-up period).  You will need it :-)



The shokunin spirit for product leaders

It is mid January.  Are you still looking for a New Year Resolution?  Here’s a recommendation.   Please watch this movie and think about your approach to your craft.  Japanese-English dictionaries define shokunin as craftsman.  After watching this movie, you realize the word shokunin means more than just craftsman.  Being a shokunin is being the best in your craft.

In the movie, the food critic Yamamoto talks about the five attributes of great chefs:

  1. Take their work very seriously and consistently perform at the highest level
  2. Aspire to improve their skills
  3. Cleanliness
  4. Impatience - They are better leaders than collaborators. They’re stubborn and insist on having it their way.
  5. A great chef is passionate

Now, those five attributes could be applied to any great product manager or product marketer.  I have watched this movie five times so far, including once with our baby sitter.  Each time I screened it for an audience the reaction was one of awe and inspiration.  Except once.  And that one time, I heard the objection that Jiro the chef did not spend enough time with his kids in their earlier years and was not setting a good example as a parent [they trained with him later - one joined Jiro in his business and another opened his own sushi place]. This is the kind of half glass empty comment that derails progress. To be great at something you have to give up something too. That is the hard truth. Fortunately for our protagonist Jiro, his sons emulate his father. Jiro actually inspires his kids through his work.

If you want to develop your craft, you have to toil hard and long, and there will be many tradeoffs along the way.  But there is simply no substitute for working hard. Whining about the tradeoffs (whichever may apply to each of us) and resisting change is a path to mediocrity and status quo. Overcoming the situation and becoming the shokunin is the pursuit of excellence.

- Prabhakar Gopalan(follow my tweets @PGopalan)

Getting buy-in for your roadmap

By Steve Johnson, Under 10 Consulting

Whether you’ve built your roadmap up from a set of features or down from a set of strategic initiatives, you want to get buy-in across the organization. Here’s a simple technique.

Roadmaps and roadmapping continue to be popular topics for product managers and product marketing managers. Perhaps it’s because roadmapping is such a critical strategic activity but no one is quite sure if they’re doing it right.

A roadmap looks beyond what you’re doing now. It explores not where you’ll be soon but where you could be a year or more down the road.

A roadmap begins with ideas, sometimes large epics or themes and sometimes just a laundry list of features and user stories. Likely you’ll have assessments of the importance of that idea to the business and to your target customers. You probably have some estimates of sizing too.

You stick all that in a spreadsheet, move some stuff around, and then present your roadmap to various internal audiences. And whap! you get smacked in the face. “Where the feature for my top customer?” “What about cloud?” “I thought the new infrastructure was going to be next.”

I’m sure we’ve all had occasions where colleagues questioned the roadmap priorities or even supported it strongly during the team meeting but then complained bitterly about it immediately afterwards. In some cases sharing your roadmap internally a no-win scenario but more often, not getting support for the roadmap results from not getting buy-in from the people who sell and support your product. They cannot see how you came up with your list and how you chose to put one thing in front of another.

So here’s a technique to align your roadmap with internal priorities.

Show them your process.

Explain the different factors you use when you’re prioritizing the roadmap: impact to customer, number or percentage of customers affected, revenue and cost estimates, strategic initiatives, and so on. Explain the formulas. You want them discussing the factors and the weights, not complaining about individual items. You want them to buy-in to the columns, not the rows. Once they see a method in your approach, they’re more inclined to support it.

But let’s take it further. Ask representatives from each team to say “yea or nea” to each item on the roadmap.

getting buyin

We’ve added a section to the roadmap for internal buy-in with a column for each organizational group. Each group can say whether that item is critical for their group or their customers. In this case, it’s clear that the first feature is important to everyone. Further down you can see the sales and marketing teams are big on the social media integrations while the post-sales groups want real-time status updates and point tracker. The leadership team seems to want everything so that doesn’t really help much (although I guess it makes them feel better.)

I’ve found that people are more inclined to support something when they’ve had the chance to define it or at least contribute to its definition.

Some facilitators choose to limit the number of votes per operational area. There are 11 items in this list; give each team 5 or 6 votes and see what happens. Like the game of musical chairs where there’s always one chair fewer than the number of children playing, this approach prevents people from choosing everything and really forces them to prioritize.

But wait. Who’s missing?

That’s right. Customers are missing.

You could use this same approach at your next customer meeting. Or use a voting tool like UserVoice to expand it to more groups. You could choose to add a column for customer votes but it’d be better if you added a column for each target market segment. Then you can see that Japan and Korea want these capabilities while Western Europe wants a different set. Or the needs of financial services compared to manufacturing.

jellybellypile200I used a similar technique with my customers using jellybeans and fishbowls. We had many big initiatives—more than we could do—and no clear strategic direction from inside the company.
So I held a customer advisory board meeting of a dozen customers. fishbowlAt the side of the room I had a dozen fishbowls, each labeled with the name of one initiative. I gave each company a bag of 50 jellybeans and asked them to vote. Some were very careful, putting 7 beans here and 17 beans there, but one customer (our most vocal) threw his entire bag of jellybeans into one fishbowl, saying “I can’t keep using your product if you don’t complete this!” This “jellybean and fishbowl” method is simple; it’s easy to explain and it doesn’t cost much.

Ideally you want to create a prioritization scheme that makes sense to both colleagues and customers and one that doesn’t require too much technology to support it.

Want buy-in for your roadmap? Solicit feedback and insights from your colleagues and customers and then show them the math.

About the author

Steve Johnson is a widely recognized speaker and story teller within the technology product management community. As founder of Under 10 Consulting, he helps product teams implement strategic product management in an agile world. Sign up for his newsletter and weekly inspirations.

User stories should be implementation free

By Steve Johnson, Under 10 Consulting

In my ebook From Agile to Agile I quoted from a post on Mark Levison’s ScrumMaster Tales:

As a first time book buyer I want to find the perfect mystery novel by reading staff reviews so I won’t waste my money reading bad books

Via email, Ed responded:

I would disagree that the user story you cited in your e-book is implementation free; you are assuming that reading staff reviews would reduce the amount of money reading bad books.

Ed wonders: did the user story begin with a problem or was it reverse-engineered from a solution the developers wanted to build. That is, were customers asking for staff recommendations? Or did the product team decide staff recommendations were cool and then wrote the user story from that premise?

And is the goal to save money? Or save time? I know I don’t want to waste my time reading bad books, an issue more important to me than money. But frankly, I’m more inclined to check the reader reviews on Amazon than rely on staff picks. Who are these staff people? Do they like the kinds of books I like?

This level of detail in user stories is an issue that concerns most agile product teams today.

I ran a series a few years back called “Req or Spec?” I’d post a user story and asked readers to comment. Some user stories were clearly implementations; others were too vague to respond to. Happily some were “just right.”

My recommendation is to write your first user stories with a product management peer or two and then discuss the level of detail. Is the story referring to one idea or more? Does the story contain implementation? Is the story specific enough for a developer to know what to design and build? Once you and your colleagues think you’ve got it nailed, have a discussion with your product team. See where they agree and disagree. You most often find they want more detail but don’t let them pull you into designing an implementation.

Do you have some to share? What are your “best” user stories and why? Post them in the comments section below.

Tweet this: User stories should be implementation free #prodmgmt #agile

About the author

Steve Johnson is a widely recognized speaker and story teller within the technology product management community. As founder of Under 10 Consulting, he helps product teams implement strategic product management in an agile world. Sign up for his newsletter and weekly inspirations.

How Important (really) is ‘Business Value’ to your Backlog Prioritization?

By Rivi Aspler

prioritiesAgile teams rely on a prioritized backlog to guide their work. Ideally, when your product owner defines a product backlog item, he or she should focus on its value to your customer. That’s the school instruction. In practice, the product owner will actually consider the following:

  • Business Value
  • Known Obligations to Customers
  • R&D Effort Estimation
  • Dependency on other Backlog Items

Business Value

‘Business Value’ should be the main driver for the Backlog Prioritization. If your backlog is well prioritized, your sales people would find it easier to sell the product, since it really brings, money-worth, value to the buying organization.

Furthermore, your backlog should consist of features that bring value to your Target / Strategic Customers, hence maximizing the chances to win large tenders.

But, life isn’t that straight forward and as a product owner, you will often find yourself prioritizing your backlog using more than the Business Value parameter.

Known Obligations to Customers

obligationsIdeally, obligated backlog items should also be the ones that bring most business value. Unfortunately this is not always the case.

This is the reason that product owners love and hate these obligations.

On the one hand, these off-target obligations contaminate their ideal product backlog with sales people promises to customers.

On the other hand, these known obligations mean that the product is out there in the field and that customers want it as long as feature A is in.

R&D Effort Estimation

Just like in real-life, ‘buying’ features from R&D you will often buy a few cost-effective items rather than one expensive feature. The example below shows such a case.

Naturally, you would rather do that with backlog items that are similarly prioritized and not invest the precious R&D time in many cheap features that are totally nice-to-have.

Dependency on other Backlog Items

Guiding product owners to break requirements into the littlest user stories, R&D is often presented with a list of user stories that each has its own business value but that technically have many cross dependencies.

In such a case R&D would present to the product owner a constraint of cross-dependencies which in turn affect the user stories grouping and hence, the product backlog prioritization.

As one can see, all of the above are known constraints that push that business value aside a bit, making it defacto, a less important than wanted parameter. Your job as a product owner is first of all to be aware of that and secondly, try to minimize the effect of the non business considerations.


Tweet this: How Important (really) is Business Value to your Backlog Prioritization? #prodmgmt #agile


Want to be a better product manager in 2013? Start here

By Josh Duncan

I wanted to start 2013 off by sharing a site that will help you with your product management work in 2013.

If you haven’t heard of it, Quora is a Q&A site with the goal is to be the place for answers. Note the tag line,  “Quora connects you to everything you want to know about“.

I remember when Quora first came out, there was a tremendous amount of hype. For a breif period of time in 2010, everyone seemed to be talking about it and then it quickly faded away as the tech press moved on the next big thing.

I was orginally impressed with the number of high profile technology and startup leaders on the site that were answering questions but quickly lost interest. It wasn’t solving a need for me and their product updates (boards, points, etc) didn’t seem like anything I needed.

I am not sure how it happened, mostly likely a shared post on Twitter, but I am now hooked. At least once a week I scan the site looking to see the latest discussions and topics. More often than not, I find a great piece of advice that applies to what I am working on or a really good random story.

How can you use it?

First, there are some great answers on the site that will show up in your feed if you follow the Product Management and Product Marketing topics. Here are few recent questions as examples:

Second, you can follow areas to increase your domain knowledge and help you find new ideas. I follow StartupsSoftware-as-a-Service-SaaS, Business ModelsInternet Advertising, and Enterprise Software just to name a few.

Finally, there are some really great stories that show up on Quora (often answered by the main participants). Here are a few examples so you can see what I mean:

Hope you find this resource as useful as I have.  All the best in 2013!


Tweet this: Want to be a better Product Manager in 2013? Start here: #prodmgmt #innovation

Image Credit: Eleaf