Tag Archives: Product Manager

3 Things Product Managers Can Learn from Management Consultants

By Alex Joseph

 

House Of LiesManagement Consultants are probably one of the most ridiculed professionals in popular culture (only next to Wall Street bankers). They are often portrayed as ruthless and self-obsessed mercenaries in Dilbert cartoons (‘Dogburt, the Consultant’) or in ‘House of Lies’, a show which is based on the book titled ‘How Management Consultants Steal Your Watch and Then Tell You the Time’!

However, most executives admire management consultants (at least secretly!) and would love to hire top-notch consultants. After having worked as a management consultant and a product manager, I have noticed that many product managers are still skeptical of ‘the consultants’, as most PMs come from engineering or design. I understand some of the concerns, but also believe that many consulting skills (apart from the passion and drive) can be extremely valuable in product management roles. Here are three of them. (BTW, according to consultants, any list should only have three items, since people can’t remember more than three things!)

Gather Data Smartly

Good management consultants are extremely analytical and are obsessed with data. Though sometimes bordering on ‘analysis paralysis’, consultants are methodical in proving or disproving their ‘hypotheses’ and often find creative ways to find proxy data, when it’s not easily available. Though often derided as ‘POOMA’ (you know what that means!), estimating something hard to observe based on something you can observe can be extremely valuable in product management, since the most interesting market data is rarely presented cleanly in an analyst report!

In my first consulting project, the engagement manager asked me (as the most junior member of the team) to analyze the success stories of the four biggest competitors. It was a painful task going through 100+ customer testimonials, but when I clustered them into industries creating a heat map (in one chart), it was an eye-popping revelation how few use cases they actually address – despite their public claims of solving every problem under the sun. It was a classic case of ’80-20’ (as consultants would call it). The conclusions were not entirely surprising, but we then had solid data to back that up, instead of getting into the ‘my opinion vs. yours’ religious battles.

Synthesize and Present Top-Down

Product managers sometimes get lost in a ton of data. I recently watched a product manager presenting a proposal using many dense data charts – pulled from various analysts segmenting the market in different ways and presenting numerous possible features and functions. At the end of the long presentation, I asked him, “Where should we focus?” His answer was, “They are all attractive, and if we have the resources we should do them all.” Something a good management consultant would never say!

In consulting, the ability to structure the message using the Pyramid Principle is extremely important. The goal is to communicate top-down with the most important message first (‘tip of the pyramid’). The supporting conclusions are presented at the next level (following ‘MECE’), resembling a pyramid. This makes it easier for the reader (and especially for busy executives) to grasp the gist of the message instead of being bombarded with a lot of rambling details.

While telling the story, most use a variation of an approach called Situation, Complication, & Resolution to drive to a clear course of action. All of these are equally important for product managers while communicating a product vision & strategy. (Good presentation on applying Pyramid Principle for structured communication).

Gallery of management consultants

Get Stakeholder Buy-In

One thing in common between consultants and product managers is that they often have to ‘influence without authority’. It’s critical for consultants to get buy-in from executives by finding common ground. Most construct a stakeholder diagram at the beginning of the project to figure out the key people to influence. Contrary to stereotypes, no smart consultant will walk in to the big meeting with a heavy PowerPoint deck without getting buy-in privately from these decision makers (‘pre-wiring’).

Product Managers (especially in a big company) have to navigate complex organizational units. Many PMs, especially those from a technical background, seem to have the naïve belief that ‘the best idea will win’. ‘Politics’ may sound like a dirty word, but it’s nothing more than using emotional intelligence while dealing with organizations and executives (that are human too!), considering their collective self-interests.

Does this mean that all management consultants would become excellent product managers? Not always, but that’s a topic for another post.

Alex Joseph is a product manager and former strategy consultant and engineer. He is now an ‘intrapreneur’ in a large software company in Silicon Valley applying what he has learned from startups and corporates. Alex reflects on consumerizing the enterprise by beautiful mobile apps on Twitter and his blog.

How I Document My Product Vision

Over the last many years, I’ve been experimenting with applying Lean Startup andThe Lean Startup Customer Development concepts to product management. I first wrote about this here. Some time ago, I wrote about the challenges I and other product professionals have faced with the traditional approach of writing a business case.

One area where I had always struggled with was finding a simple and quick way to sketch out my product ideas. I used PowerPoint, Word, Google Docs, but they never really worked effectively. Often times my original notes would grow into a bloated morass of detailed thoughts about features, customers, marketing, partnerships, technologies, etc. There was no structure. Worst of all, if I wanted to share them with someone, I’d have to spend time figuring out how to translate them into something readable, since no one would be able to decipher my chicken scratch.

Before writing a requirements doc or business case, what I really wanted was a way to not only quickly capture a product idea in a structured manner, but also use the same format to share it with others to elicit feedback.

So you can imagine my delight when I came across Alex Osterwalder’s Business Model Canvas several years ago.

Business Model Canvas

What’s great about it is since it’s a single page, one can quickly jot down the basics of any business model, and it’s easy to share and more likely to get read than a PowerPoint deck or a Word doc. The single page also forces brevity: there isn’t a lot of space for a laundry list of features – you need to distil down your idea to its most essential building blocks.

Love at first sight, I started trying to use it for my products. But I ran into a few challenges. I found that while it does a good job capturing the key elements of a business, it’s not as customer focused as I would have liked because there was no place to capture the customer problems I was trying to solve or identify potential early adopters. There was also no place to capture my envisioned solution, and I often got confused between Channels and Customer Relationships.

That’s when I came across Ash Maurya’s Lean Canvas, an adaptation of the Business Model Canvas he created for his web startups.

Lean Canvas

Ash has correctly put the focus on customers and their problems. I also like that he calls out Unfair Advantage, which to me means competitive differentiation. This is especially true for a startup that may be fighting bigger, more established players.

So I started using his Lean Canvas, but ran into a new set of problems as a product manager:

Resources: Ash has left this out from Alex’s original version. I can understand this with respect to startups, but as a product manager working in an organization, it was important to me to identify which resources – platforms, systems, departments, vendors, etc. – I would need to make my product idea a reality.

Readability: When walking someone through a product or business idea, my inclination is always to start with the market opportunity, which means customers, their problems, and how we can solve them. I found neither of the above two canvases easily lend themselves to that flow. I’d have to start at the right-most column and then jump back left. This is non-intuitive to most English-speaking readers, and I found I’d quickly lose my audience as I criss-crossed columns.

Two other challenges I ran into as a product manager:

Stakeholders: Product Managers have to deal with internal stakeholders. The larger the org, the more. Often times a new product idea needs an executive sponsor. In my experience, I’ve found that the more I’m mindful of who are my key stakeholders, the greater the chance of internal support for my product.

Non-Revenue “Products”: Some products managers are responsible for initiatives that aren’t directly revenue generating, but do provide tangible business value, like improving CSAT, driving referrals, etc. I’ve lead several like that.

So I decided to create my own iteration that I felt was more suitable to me as a product manager, that I call the Product Canvas:

This version puts the customer and market on the left-hand side, which not only addresses the readability issue but also supports more intuitively how I think through a product opportunity. I can start with the customer and their problems on the left, and work my way toward the right to ultimately figure out how I’m going to deliver on the solution.

Here’s a brief description of each block and the order in which I typically approach them:

1. Customer Segment: Who is the target customer of our proposed product? This could be the company’s entire customer base, a segment, or a new market or vertical. Ash recommends using a separate Lean Canvas for each segment where one has multiple segments in mind, and I think that’s good advice as a starting point.

1a. Early Adopters: For any new product opportunity, it’s important to identify early adopters. There is already a ton written about this. While identifying early adopters is implied in the Lean Canvas, I wanted it called out explicitly, as I’ve found even in existing organizations there is a tendency to think any new product idea is applicable to all customers.

2. Problem: A brief description of the top problems we’re addressing. I try to limit this to at most 3.

2a. Existing Alternatives: How is the customer solving this problem today? This may not be just direct competitors. For example, in the early days, Quicken’s competition was not only other accounting software, but also checkbooks, and pen and paper.

3. Unique Value Proposition: How are we uniquely going to solve our customers’ problem(s)? This is the elevator pitch: the one sentence that clearly states the value we’re providing to our target customers.

4. Solution: What are the most essential features of our solution that will deliver on our UVP? This is not an exhaustive feature list. I try to limit it to the top 3 elements of my proposed solution.

5. Channels: How will we get (acquire), keep (retain), and grow (sell more to existing) customers? What is the marketing and sales strategy?

6. Revenue Streams/Business Value: How will we make money? What’s our pricing strategy? If this is not a revenue generating product, what other business value is it providing? Improving customer satisfaction? Customer lifetime value? Market positioning? Competitive differentiation? Operational efficiencies?

7. Key Metrics or Success Factors: What are the most important metrics that will tell us that we’re successful? Signups? Conversions? Referrals? CSAT? NPS? These are the metrics that are driving #6 above.

8. Key Resources: What are the most critical internal resources we need? These could be platforms, systems, business processes, departments. Are there external partners we need to rely on?

9. Cost Structure: What are the key cost drivers? Software/IT development? Customer acquisition? Account management? Hiring and talent development? This is also a good place to capture a back-of-the-envelope break-even calculation.

10. Unfair Advantage: This is the distinctive competence or advantage that your product has over other solutions in the marketplace. It’s something your product does better than any other, something that can’t be easily copied. It could be intimate knowledge of an industry, personal authority or brand, a business process or competence, a patent, or some other intellectual property.

After experimenting with using this Product Canvas as a product manager, I started sharing it with folks, asking them to use it, and the feedback has been very encouraging.

Feel free to download it here.

Guidelines For Conducting A Customer Conversation Session

By Prashanth Padmanabhan

There are some basic principles that you can follow while telling your story to your customer.

1. Show up at the customer’s office, if you can.

It shows respect. It tells them that you care for their thought. It is money well spent. As a product manager or product designer you are the voice of the customer and that is your only advantage over every other function. So customer visits should be your number one priority. Nothing else is more important than that.

2. Always show a prototype or draw a picture on the white board.

Don’t show a set of slides. This forces participants to think differently, look at the prototype and imagine rather than go into a passive finger-pointing mode. The prototype must include a list of concepts that you want to confront them with for feedback. Organize those concepts in the form of a story you can tell by going through the different screens in the prototype. Pause for a few seconds after each concept is outlined and let the interviewees share their thoughts. Acknowledge any interesting thoughts that come up and move on to the next concept in the story.

3. After introductions, ask them what they plan to get out of the session, and write that down on a flip chart.

If the crowd is large, ask everyone they plan to participate or if they are merely there to observe. Differentiate between the participants and observers and direct the conversation to the participants.

4. Listen more. Speak less.

You should be talking for about ten percent of the time and listening for the reminder of the time. If you have a hard time keeping quiet, take on the role of the writer on the flip chart. This will help you talk less and listen more. It will force you to keep quiet and will nudge customers to think aloud and direct you writing.

5. Write or draw on a flip chart.

Don’t sit down in a chair and write in a notebook where no one can see what you are writing. Writing on a flip chart, conveys to customers that you are listening, synthesizing and are open for comments. They can see your thought process, point out gaps in your thinking and, if necessary, correct what you write. So take notes publicly. Not privately.

Tip: Avoid total silence when in a conference! If you are running a workshop via conference, while taking notes, please avoid silence. Tell the customer you’re taking notes so they know you are listening.

6. Display all the flips charts all the time.

Do not flip the chart over and go to a new page. Tear the paper you wrote on and tape it to a wall. Don’t worry. Customers do not mind you posting 4-5 flip charts on the walls of their conference rooms. Pausing to tape the flip chart paper on the wall will give you a logical break after about 15-20 minutes of conversation. If your colleagues are present, it will give them an opportunity to chime in. It will also give you a minute to collect your thoughts.

After your paste the flip chart on the wall, underline the key words in the notes, recap the conversation, point out who said what, and ask participants if you missed anything. It gives participants an opportunity to point of simple errors that are bothering them.

7. Document while at the session.

Not after you come back to the office. Use a (phone) camera to take a picture of all the flip board charts. That is you documentation. You don’t have to write elaborate notes after you come back from the session. Post the pictures to a collaboration site, such as Streamwork, SuccessFactors JAM, Yammer or SharePoint, along with the notes and share it with customers.

8. Capture customer quotes and share them with colleagues rather than writing elaborate reports. Your colleagues will appreciate the quotes from customers and users.

Prashanth Padmanabhan is an entrepreneur, product designer, collaboration enthusiast, product manager for people and work management software, and SAP mentor. He’s co-authored two books, SAP Enterprise Learning and Look & Flow, a book on product innovation using design thinking and storytelling. His blog is Journal on Product Design and Development.
This post was originally published on Look and Flow, the blog site for his book. It is reprinted here with permission.

Productivity hack for the busy product manager

I like getting things done. Who doesn’t? And as product managers, we’re wired to get things done.

But it’s hard, isn’t it? So many things seem to get in the way.

Meetings.

Requests from team members, other departments, your boss, and higher ups.

“Voluntold” responsibilities.

Emergencies and “fires to put out”.

Administrative distractions.

All conspire to keep us from doing the things we really wanted to get done.

And don’t even get me started on email. Or messaging apps.

We often find ourselves racing from meeting to meeting, request to request, crisis to crisis, spending too little time on doing activities that support our higher goals.

And as a result, too many of our days can end in frustration. On Friday evening you look back, and though you’ve certainly done a lot of things, you’ve been busy, you feel like you’ve accomplished little to few of the things you had originally wanted to at the start of the week.

Several years ago, I discovered a productivity hack that’s been working well for me. And I want to share it with you.

At the start of every week, I write down: “What are the 5 things I want to accomplish this week?”

I usually do this Sunday evening as it enables me to begin the transition from weekend mode to work mode come Monday morning.

Then, either at the start of every day or the evening before, I write down “What are the 3 things I want to accomplish today?”

I call these my priority lists. I then have a third list I simply title “To Do’s”. This is my generic, catch-all to do list. Any new item gets added here first. Generally, I try to keep this prioritized, but I don’t sweat it too much. These items have the opportunity to get to my priority lists during my daily and weekly reviews.

I then have a third list I simply title “To Do’s”. This is my generic, catch-all to do list. Any new item gets added here first. Generally, I try to keep this prioritized, but I don’t sweat it too much. These items have the opportunity to get to my priority lists during my daily and weekly reviews.

I place all three lists in a place that I frequently access and is highly visible, such as a note in Evernote or some other place. All three lists are in the same Evernote note, and I always update that same note, never create new ones. I first list my 5 goals for the week, then my 3 goals for the day, and then the generic to-do list. Every item is listed with a checkbox (a very cool feature in Evernote). This gives me the immense gratification of checking off completed tasks.

I first list my 5 goals for the week, then my 3 goals for the day, and then the generic to-do list. Every item is listed with a checkbox (a very cool feature in Evernote). This gives me the immense gratification of checking off completed tasks.

Every item is listed with a checkbox (a very cool feature in Evernote). This gives me the immense gratification of checking off completed tasks.

I’ve titled the note “TO DO LIST”, in all caps, and have added the tags “FAVORITE” and “IMPORTANT”. Because it’s the note I most frequently access, Evernote automatically keeps it at the top of my notes. These little things together enable my to-do’s to always be front and center for me.

You could just as easily use Google Docs, Word, a to do list mobile or web app, a project management system, or even a plain old notepad. I use Evernote because it’s something I use every day, and my notes are accessible to me on every one of my devices.

Finally, I stick to One Rule: only truly urgent things supersede any item already on the priority lists.

What I like about this system is its simplicity and ease. The act of listing to-do’s in the first two lists means I’ve prioritized them. So as I get them done, I enjoy the affirmation that I’m doing things I’ve deemed most important.

Also, if I see any item sitting in the general to-do list for some length of time, it starts to bug me. That forces me to either prioritize it for a particular day, call an audible and get it done immediately (subject to the One Rule), or take it off the list permanently. If it’s been there that long, it probably wasn’t terribly important to begin with, so off it goes!

After an initial period of establishing the routine, I’ve found my productivity level improve dramatically. It’s also enabled me to plan my calendar better. Most importantly, it’s given me a sense of accomplishment and purpose.

Try it for yourself. And share in the comments below what hacks and tricks you’ve used that have worked for you.

The Case Against The Business Case – Part II

Note: This is part of 1 of a two-part series. Read part 1 here.

In part 1, I talked about the problems of pursuing a new product idea in an organization, which traditionally starts with preparing and selling a business case. I shared research that I conducted in which I spoke with a number of product management professionals across the country in companies large and small who resoundingly shared their distaste for the process.

The response was amazing. It seems my post touched a chord!

Some interesting stats:

  • Within one week, the post became the 3rd most viewed on my blog.
  • Tweets, likes and positive comments on my blog and LinkedIn groups where I shared my post totaled 31. In other words, 31 additional people were in agreement with the original 24 with whom I had spoken.
  • On the flip side, there were a 6 disagreeing comments posted on the same LinkedIn groups.

Now, if there were any other detractors (because many more viewed the article), they either didn’t agree, didn’t comment, or didn’t care.

Still, with 83% promoters and 17% detractors, this would give an NPS-style score of 66%.

So it seems I’m on to something here.

Here’s something interesting. According to the Pragmatic Marketing’s 2013 Annual Product Management and Marketing Survey, 50% of respondents indicated they spend at least half a day per week preparing business cases.

part-of-job

Do the math on this, and that’s 17.6 hours per month or the equivalent of 1 month and 3 days per year spent preparing business cases.

So on average, a product manager is spending over one month of an entire year preparing business cases. Surely there should be some ROI to spending that much time? Yet, we all know the rate of failed products is sadly high.

To be clear, I’m not saying a business case is not necessary. Indeed, one needs to have a robust business case to ask for a commitment of resources and/or investment.

I’m saying that while well-intentioned, somewhere along the way, the process by which we’ve gone about preparing the business case has become wasteful.

[optin-monster-shortcode id=”tjtsmjhkd0zsxede”]

 

Several months ago, Steve Blank wrote a column in the Wall Street Journal that talked about the need for a startup to begin not with a business plan, but with building and testing a business model.

Three years prior to that, he blogged about how Customer Development is more effective than the traditional product development process in helping startups raise VC money.

“In a traditional product development model, entrepreneurs come up with an idea or concept, write a business plan and try to get funding to bring that idea to fruition. The goal of their startup in this stage becomes “getting funded.” Entrepreneurs put together their funding presentation by extracting the key ideas from their business plan, putting them on PowerPoint/Keynote and pitching the company – until they get funded or exhausted.”

It seems to me the same logic can be applied to pursuing new product ideas in established organizations.

Just like entrepreneurs typically jump right into writing the business case and seeking funding, product managers (or any visionary employee) often go direct from coming up with a concept to writing the business case and seeking its approval.

traditional-biz-case

Here’s another quote from that WSJ article:

“Entrepreneurs treat a business plan, once written, as the culmination of everything they know and believe. All they need to do is add money and magically that five-year forecast in Appendix A will simply happen if they execute to the plan.”

I’ve found the same with business cases. There are two key problems with the traditional approach to preparing a business case.

One is, like with startups, pursuing a new product idea in an organization is also fraught with uncertainty. The assumptions that go into the financial forecast need to be tested.

The other is that when seeking approval, your goal and your execs’ goal may not necessarily be aligned.

You still have a lot to learn and prove in your model. But the execs are ultimately interested in only one thing: ROI. Perfectly understandable, given the financial responsibility entrusted upon them.

problem-with-biz-case

This often leads to wasteful execution. The focus becomes hitting an arbitrary delivery date and trying to hit a promised ROI.

The product manager is caught between a rock and hard place: learning from customers and launching on time. It often leads to delivering bloatware or crapware.

What was that stat again about the rate of failed products?

So it seems to me that to build a robust business case, it’s important to validate that you’ve truly understood your customers’ problems, that they’ve bought into your proposed solution, that the problem is worth solving, and that it fits with the company’s overall corporate strategy.

For extra credit, you need to identify some early adopters, or “earlyvangelists,” as Steve Blank calls them.

These insights can help you identify key metrics that will drive your financials, making for a much more solid business case, and increase the chances for more efficient execution.

To add to this, product managers face a unique challenge that entrepreneurs don’t, which is gaining and maintaining internal stakeholder support.

This can be especially true in larger organizations where there are simply more people to manage and placate. Lots of opinions. Capturing and addressing concerns. Following up. Competing agendas. Finding an executive champion. Lots of approvals.

These are real challenges with which the bold product manager has to deal.

How to address that? Perhaps there’s a way to apply Customer Development concepts to internal stakeholders…?

In fact, there is.

Before Product/Market Fit comes Opportunity/Company Fit

In his book, Running Lean, Ash Maurya presents a workflow for taking a product from idea to launch to Product/Market fit.

Ash Maurya workflow
In the Problem/Solution Fit stage, you are trying to answer the question, “Do you have a problem worth solving?” Ash breaks this down further into three questions:

  • Is the problem something customers want solved? (must-have)
  • Can it be solved? (feasibility)
  • Will they pay for it? If not, who will? (viability)

Problem/Solution Fit is pursued by capturing your business model hypothesis and then doing Customer Discovery via problem interviews and solutions interviews with customers. Once you’ve validated from customers that you have a viable problem worth solving, you move into Product/Launch Fit.

In the Product/Launch Fit stage, you are trying to answer the question, “Are you ready to learn from customers?” Key activities pursued here are reducing down your MVP, getting to Release 1.0, defining your key metrics, and continuous deployment. The purpose here is to lay the critical groundwork to maximize speed and learning for future iterations, and to establish “just enough” traction among customers to support learning.

Finally, in pursuing Product/Market Fit you are trying to answer the ultimate question: “Have you built something customers want?” This is where the rubber hits the road, and you’re validating your complete product. Identifying the “right” metric or set of metrics, prioritizing your feature backlog, and ensuring retention and getting paid are critical to the success of achieving product/market fit.

This Lean Startup workflow is one that could be used by a product manager pursuing a new product idea or looking to introduce an existing product into a new market. After all, the product manager in such a situation must be able to answer the same set of questions about who is the customer, what customer problem is the product trying to solve, and will enough customers care enough to pay for the solution. The product manager typically starts with some sort of informed hypotheses to answer these questions, which form the basis of the product vision. And the product manager must stay in close touch with customers to validate whether the product is truly something they want.

I feel there is one critical step missing in this workflow, though. It has to do with the unique situation product managers find themselves in versus entrepreneurs. Whereas an entrepreneur is trying to discover a business model that works, a product manager is typically an employee in an existing company already executing a repeatable and scalable business model. As such, the new product idea being pursued by the product manager could represent a change to the company’s existing business model. As such, because of the potential impact on the company’s existing business model, a critical consideration for the product manager pursuing a new product is whether the new product is aligned with the company’s corporate strategy.

In his book, Product Leadership: Creating and Launching Superior New Products, author Robert G. Cooper talks about the need for new product development efforts to be closely linked to the overall business strategy. In Beyond the Core, Chris Zook makes the case that the further a new product or business idea is from the core business — what he calls an “adjacency move” — the riskier it is and more prone to failure. What this means is that the more closely aligned the new product idea is to the company’s existing business strategy, the more favorably it will be looked upon by the company’s executives. This does not mean something completely outside of a company’s existing core will never be approved. But it does mean the bar to get that buy-in is much higher.

So in order for the new product idea to garner the necessary stakeholder support, its business case must be able to articulate the business opportunity it presents to the company, how it fits (or departs) from the company’s current business model and strategy, and the risks associated with pursuing it.

As such, Ash’s workflow can be modified as follows:

opportunity-company-fit

I call this stage Opportunity/Company Fit.

Critical questions for the product manager to figure out are:

  • Does the idea align with the company’s strategic goals?
  • Who do I have to convince to get buy-in?
  • Can I get a sponsor? Who?

Just like with using customer validation to achieve Problem/Solution Fit, I’m sure it’s possible to use lean principles to achieve Opportunity/Company Fit.