Month: January 2013
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.
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 http://wp.me/pXBON-3Lr #prodmgmt #innovation
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:
- Do any of you Product Managers or Product Marketers get invited to Club?
- If so, what is the criteria used to qualify?
- 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? http://wp.me/pXBON-3Lz #prodmgmt #sales
by Steve Johnson, Under 10 Consulting
You: “When’s dinner gonna be ready?”
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”.
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.
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 www.planningpoker.com 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 http://wp.me/pXBON-3KO #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.
By Saeed Khan
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
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? http://wp.me/pXBON-3KZ #prodmgmt
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.
If 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 honest. Make 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