In A Framework For Evaluating Market Opportunity, Neal Cabage asks:
How do you know whether a product idea is going to succeed if you build it and take it to market? If you’ve ever been part of a startup, or if your organization has launched a new line of products, you know how precarious the effort can be.
That is the challenge that led to the creation of the ‘product opportunity evaluation matrix’ or POEM framework.
Read more here.
There cannot be a stressful crisis next week. My schedule is already full.—Henry Kissinger
Henry Alfred Kissinger is a German-born American writer, political scientist, diplomat, and businessman. A recipient of the Nobel Peace Prize, he served as National Security Advisor and later concurrently as Secretary of State in the administrations of Presidents Richard Nixon and Gerald Ford. After his term, his opinion was still sought by some subsequent US presidents and other world leaders. Learn more…
A recent survey reveals product managers and product marketing managers spend 46% of their time in firefighting. With so much time focused on operational issues and emergencies, when are you going to work on the critical core documents that drive your product strategically?
Let’s look ahead just a bit. Sometime in the next few months, you’ll need to prepare a business case or a product plan or a strategic roadmap. The usual approach is to pull a few all-nighters and hope you don’t get tagged by anyone for additional detail. However, I’ve always kept a binder (or a folder) filled with the living documents of my product. A financial plan, a prioritized backlog, personas, positioning, roadmap.
Start working on those now! Complete one document at a time.
And then when it’s crunch time, if you’ve been working on the core items of the business of your product, it’s more of a copy-and-paste exercise. It’s edit, not compose. Much easier.
In my coaching sessions, I help teams identify which activities are important and then assess how well they’re being done–not surprisingly, the most important product activities are usually the ones which are being done poorly. With a simple red-yellow-green indicator, we can identify which activities need our attention. My goal is to help teams turn those important areas to green–showing a high level of performance.
Need help? Check out my Pragmatic Marketing implementation assistance.
“Supposing a tree fell down, Pooh, when we were underneath it?” said Piglet.
“Supposing it didn’t,” said Pooh after careful thought.
Piglet was comforted by this.
—A. A. Milne
Alan Alexander Milne was an English author, best known for his books about the teddy bear Winnie-the-Pooh and for various children’s poems. Learn more…
I’ve seen many product managers attempt to write business plans and development documents and sales tools accounting for every possible contingency. (“Suppose a tree fell down!”) And yet, some things you anticipated never occur, and the ones you didn’t anticipate frequently do. (“Supposing it didn’t,” said Pooh.)
We do what we can to prevent failure. And that’s good. (That’s the value of my Under 10 Planning Canvas.)
Instead of trying to anticipate everything, help your executive teams, development teams, and sales & marketing teams use their judgment by understanding the product strategy and your market’s mindset. People will invariably use your products in ways you didn’t intend. And your colleagues will find situations not covered by your FAQs and user stories. Share personas, a “day in the life,” a few common use scenarios–don’t try to flowchart every possible outcome.
(Piglet was comforted by this.)
You should be too.
Need help? Check out my Pragmatic Marketing implementation assistance.
Trying not to fail is not the same as striving for success.—Art Petty.
Art Petty focuses on helping clients develop as high performance professionals and helping owners and executives build high performance programs and teams. Learn more…
A lot of product management is mitigating risk. We estimate revenues and costs, prioritize features and stories, and try to articulate a message that resonates with buyers—all in the hope of making the best choices for our organization.
We do what we can to prevent failure. And that’s good. (That’s the value of my Under 10 Planning Canvas.)
But as Art says, preventing failure isn’t the same as striving for success.
The next time you’re planning, think bigger. Think about what would make your product insanely great. Not ten percent better but ten times better. Don’t settle for “it’s the best we could do” but strive for “it’s the best!”
Need help? Check out my Implementation coaching.
When you’re looking at a new product situation, whether you’re a leader in an investment firm, a general manager, or a product manager, where do you begin?
In my recent discussions, the top three areas of concern for leadership are:
1. revenue generation
2. operations
3. product development
From my involvement with Primary Intelligence, and also with Alan Armstrong of Eigenworks and Adele Revella of Buyer Persona Institute, I’ve become a real fan of win loss analysis. That’s where to begin as you look at problems in your revenue generation. Win loss analysis answers the questions: “Why do we lose deals?” and “Why do we win deals?” It’s likely you’ll find from win loss analysis some simple things to fix in sales training and coaching, sales enablement, and leadgen, but you’ll also find some areas of the product and operations that could use your attention.
“Operations” covers a lot of areas, depending on your type of business. Challenges in this area generally undermine the efforts in revenue generation. In manufacturing, you want to look at each of the steps of your supply chain. In software, you want to look at your online services, support, and professional services offerings. Cumbersome methods and mistakes in operations sap your company’s profitability.
Once you’ve got a handle on sales and post-sales support, it’s time to look at product development. But what I hear most often is not the mechanics of developing products—agile methods seem to have taken care of that. What I hear is roadmapping and prioritization. What I’m hearing is that we don’t have a product development problem; we have a product management problem.
The executive team doesn’t know what’s planned or how the choices were made, and they fear that the team is working the wrong things.
One company is moving from on-premise to cloud. They’re moving pretty slowly. And the team has focused on some not-very-interesting features first. Now, there may be some logic behind the roadmap—infrastructure before features, for example—but the exec team can’t see it. What’s happening beyond the next sprint?
In Getting Buy-in for your Roadmap, I explained a technique for prioritizing based on market need plus popularity of the idea internally.
For most companies, it’s best to look first at impediments to selling, next look at profit leaks in operations, and then you’re ready to take on product development and management.
My Under 10 Product Planning Canvas helps you define the optimal planning process for your organization. Need help? Contact me.
An agile consultant explained that the best way to get senior leadership on board with agile is for them to get Scrum certified.
Huh?
That’s like saying developers should attend sales methodology training.
That’s like saying you can’t enjoy the meal if you didn’t cook it.
And here’s the interesting question:
Why do senior leaders need to know anything at all about agile?
I’m an agile advocate. I’ve worked with teams who can deliver better results sooner. I love the emphasis on conversations over documents, and the ability to adapt to changing requirements. But that doesn’t mean I think everyone in the company needs to know the mechanics of agile methods.
I realized it this weekend:
Agile is a religion.
I grew up in the Deep South. I know religion. I know about being born again. I know about wanting to spread the good news. And when people of faith get together, they want to talk about their passion, their beliefs; they want to tell their stories. And I’m not just talking about traditional religion here. Other religions include self-help programs, Pragmatic Marketing, exercise, being a vegetarian, and the 125 minutes of awesome that is Star Wars, Episode IV: A New Hope.
With any passion, unless you too are among the converted, you mostly don’t want to hear it. You’re glad that your friends have found a new way, a new direction; you’re glad that they’re glad. But enough already.
Just like agile.
Here’s what senior leaders need to know about agile.
With agile methods, we can adapt to change quickly (but not constantly).
Management needs to know that you are able to make adjustments to align with business realities. And that’s what agile is really about.
Want to know more about product management and agile? Read my free ebook: From Fragile to Agile.
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 “yay or nay” to each item on the roadmap.
Each idea has one point already built in, since the idea had to be accepted by product management to get on the list. 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!
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.
This method enables you to earn buy-in from your colleagues and leadership.
But wait. Who’s missing?
That’s right. Customers are missing.
Some companies prefer to keep their internal plans internal. But others—particularly startups—find sharing their roadmaps can be a great way to promote and validate innovation plans.
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 certain capabilities while Western Europe wants a different set. Or you can distinguish the needs of financial services from those of manufacturing.
I 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. At 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? Create a prioritization scheme that makes sense to both colleagues and customers and that doesn’t require too much effort to support. Solicit feedback and insights, and then show them the math. When they understand the logic behind your longer-term plans, they feel part of the process—and are more likely to get on board.
At the start of each year, I read a book to spark my strategic thinking. I usually find that re-reading a classic reveals that my point of view has changed since the initial read and I pick up much more the second time around.
This year, I’m re-reading Blue Ocean Strategy by W. Chan Kim and Renee Mauborgne. As I’m reading it again, I wonder if it’s possible to predict a successful strategy. It’s certainly easier to work backward from success and use value innovation as a tool to explain the success. As a predictive tool, the authors argue that you can identify which de facto standards for the industry are out of sync with the buyer’s value. Is the authors’ “value curve” idea a predictive tool or an evaluation tool?
I don’t think this is from the book but I’ve always been impressed at the virtual overnight success of Marriott Courtyard. In the late 70s/early 80s, Marriott noticed a surge in female guests–women traveling alone. At that time, many women were moving into sales jobs and customer implementation jobs; they were traveling for work. So Marriott interviewed these women to see how their traveling requirements were different from women who traveled with family or men who traveled for work.
Think about it for a second. What do you think those requirements were?
The number one issue with women, as you probably guessed, was security. So Marriott designed around safety… in particular, offering limited access to the sleeping rooms and (I read somewhere) the name “Courtyard” was chosen because of its safety connotations.
What other requirements come to mind?
And what can you eliminate? If travelers have a rental car and mostly work at the client site, you can eliminate the concierge, meeting rooms, catering, and a fancy restaurant–all de facto standards that a hotel “must have” according to industry leaders. Take a look at the value of various hotel amenities for traveling business people and compare these values to what’s delivered by full-service hotels versus low-end motels. It might look like this:
For this buyer persona, it’s clear that hotels are over-performing in areas that are not valued and low-cost motels are under-performing in areas that are valued. Courtyard focuses on those areas that are valued and dramatically reduced or eliminated in areas that aren’t valued.
So my question is this: can this type of assessment be a predictive tool for your products? Of course to make it a relevant exercise, you’ll really have to know your customers and what they value. Want to try? I put together a simple spreadsheet. Download this [value-assessment] template and try to determine the ideal value curve for your products.
Executives, sales people, and marketing leaders are often frustrated with the short-term focus in product management, particularly those using agile development methods. Leaders have no idea what is planned—if anything—beyond the next two-week sprint. And that’s why they ask for a roadmap.
A portfolio roadmap has become the preferred way to show delivery plans over time. It’s not just a desired feature list by month; it’s bigger than that. It describes major blocks of work, not a laundry list of features.
Yet only 15% of organizations worldwide have deployed multi-year product strategies and less than half of these organizations admit to having done so effectively. Additionally, 20% of organizations reported relying primarily on tactical product roadmaps as the primary vehicle to align with their company’s business strategy. (See The Study of Product Team Performance.)
There are two ways to build a roadmap. Most agile teams reverse-engineer the roadmap from their list of user stories. And this bottom-up approach can work. You look at the personas and problems described by all the user stories and look for common themes. Then group similar capabilities together, get a rough sizing, and plot it on a timeline.
A better approach is top-down. Look at big ideas—often huge ideas—and spread them across time. You can see that this has to happen before that. Then for each, you break those down into the user stories that deliver on that capability.
I can envision the roadmap for my favorite online travel tool: Tripit. If you travel a lot, you should totally check it out. But here’s the gist: Forward the confirmation emails for your flights, hotels, and cars to TripIt. They’ll collate all the info into a coherent, chronological itinerary that you can manage online, and then print or view from your phone. Need a confirmation number at check-in? Need to know which hotel you booked? Which car agency did you use? It’s all right there in TripIt.
Obviously, TripIt couldn’t deliver all this goodness is one release. They needed to get a basic product out into the market and start building a following. New capabilities rolled out every few months.
Here’s how I saw it:
1. Integrate confirmations via email from the most common travel services such as airlines, hotels, and rental cars
2. Friends network: see who’s near when traveling
3. Admin support: create itineraries for others
4. Share trips via calendars
5. iPhone app
6. Android app
7. Real-time status updates
8. Social media (tell people where you are)
9. Point tracker (track frequent flyer miles & hotel points in one place)
If you look at this list, you can see that each item is a project by itself. A quick estimate from a development leader will tell you roughly how many months each project will be. Now you’ve got a roadmap. Some items may have been done in parallel by different groups but they could just as easily have been done one after the other, which is why sequencing into a roadmap is so critical.
You’re probably using EXCEL for your backlog or roadmapping tool. If so, you’ll want to have these fields in your spreadsheet:
With these fields, you can easily build a pivot table like this:
Our goal is to define the major sets of work, sequence them in a way that makes sense to the customer and the business as well as balance the effort over time. You’re not trying to do a project plan here but it’s obvious that you don’t want to attempt 20 person-months of work in one quarter with only 5 person-months in the next.
Of course, each of these items needs to be reduced to the many, many features, user stories, and tasks necessary to make the idea a reality. But without a vision for 12 to 18 months, agile teams can keep building feature after feature. Without a roadmap, agile teams are in danger of building the wrong thing faster than ever before.
Need help refining your roadmapping method? Contact me for onsite consulting.
Planning and analysis are often missing from today’s product management. We’re so caught up in product operations—answering daily questions for development, sales, and marketing—that we have little time for anything else. And planning doesn’t mean people locked in their offices, thinking deep thoughts, and creating myriad documents that no one ever reads.
I have come to believe that most organizations need a small number of living documents—fewer than 10—to manage their products and services. I believe in minimal process, brief artifacts, and living documents.
In my product leadership roles I always have a (small) collection of documents that reflect the current state of my product(s). Sometimes I have a standard price list; sometimes a financial model. Sometimes it’s a set of positioning documents by persona, or perhaps a roadmap of the next few releases. These living documents are the ones that I reference often. Once I kept them on paper in a notebook; now I keep them in a shared folder to access from my computer or tablet.
What are the templates? Here’s a list of fewer than 10:
Are there more? Surely you can think of some. But the issue is not how many documents you can have; the question is how few? We want to have the smallest number of living documents that balance the company’s need to mitigate risk while ensuring business agility. You need to move the the product or portfolio team toward success but too many artifacts, meetings, checkpoints result in a slow-to-market company.
The set of documents varies by company. The ownership of these varies by company too; they may be maintained by product manager, product marketing managers, product leaders, or others.
Use the Under 10 product planning canvas to profile your planning process.
