I'm Not Actually a Geek

When customers want a product roadmap, do this instead

February 10, 2014 by Hutch Carpenter 8 Comments

Product roadmaps suck.

There, I said it. <exhales>

OK, let’s explain that. Roadmaps that are real, living documents representing what you will deliver…are awesome. But that may not be the case for you; it wasn’t for me. Instead, a product roadmap was at its core a sales document for a prospect call. A lot of effort, with various people weighing in on what should show up there. Ginning up dates over the next 24-36 months for when features will be delivered. A visually lickable timeline.

And it’s defunct as soon as it’s published. Poor roadmap, it never had a chance. If anyone actually remembers what was in the roadmap months later, you’re left explaining that, “um…yeah…things changed”.

To be fair, this happens more in industries where the level of uncertainty is high. You’re assembling the future, learning as you go along and making adjustments. Industries with stability can put a roadmap out there and stick to it. But if your industry has a lot of fluctuation in its future, roadmaps are an exercise in futility.

Given this, what’s the point of creating them? For me, a better way to handle the inevitable roadmap requests was needed. Internally for client-facing peers; and with sales prospects and current clients. I took the view that the customer’s roadmap request was essentially about these three questions:

Where will your development resources be focused over the 12-36 months?
Does your view of what’s needed for successful outcomes matches mine?
What are the core values of your platform philosophy?

In other words, knowing that X feature would be rolled out in 12 months wasn’t really what influenced the customer. It wasn’t as if they said, “Oh, that feature will be there in a year? I’ll pay $X for your platform today and begin to use it once that feature is ready.”

I wanted to find a better way. Answer the questions the customer has while avoiding unrealistic commitments and schedules. So I developed a different approach to requests for a roadmap. It focuses on two core elements:

Product themes
How we’ll work with the client

Themes are the future the customer is buying. Work with the client describes the ongoing interactions around product design. Both are part of the decision calculus of the customer. Should I go forward with this company or not?

Product themes

Product themes are the core areas that are the means to the outcomes customers seek. When I worked at Spigit, I developed five core themes (conceptualized in below graphic):

Themes are the broad areas in which the platform needs to excel. They are selected because they are key to satisfying high-level jobs-to-be-done. They will vary by product. An accounting app might have themes around ‘accuracy’, ‘sync with GAAP’ and ‘integration with other apps’. A supplier of chemicals might need to concern itself with ‘potency of compounds’ and ‘safety’.

Themes are where an analytical approach meets a flair for artistry. Internally, they are great for organizing future release efforts. I would actually grade the platform on the themes, using the A to F scale, to help prioritize future effort.

For customers, themes provide a peek into what makes your platform special. You’re communicating a promise for what future releases will address. Customers develop a sense of the platform today, and the platform of the future.

Past + possible features = proof

For the themes, plan on doing more than stating them. Bring them to life by talking features. Yes, this sounds like the roadmap rat-hole. But it’s a different way to do that:

Past features are proof that you are focused on the themes, and they illustrate how you have approached enhancing the themes for clients thus far. They connect the experience of your product today to the themes.

Possible features are a source of excitement, and proof that you’re focused on the themes in future development. They’re not supposed to be a committed list of features over the next 3 years. Rather, they provide a sense for how you’re approaching fulfillment of customers’ jobs-to-be-done. This gives you the chance to talk about some of the ideas floating around in your organization while avoiding the farce of putting dates on when (and if) they’ll be delivered. When asked, I put it to them straight: “These are several ideas we currently have for this theme. What are your thoughts on them?”

Which leads nicely into the other major point to cover…

How we’ll work with the client

In the B2B market, customers want to have direct input into the product design process. Not so much in the consumer market, where we simply stop buying something if it doesn’t satisfy us. But the dollars and reputation that can be on the line in the corporate market translate into greater interest in where the product is going.

To address this desire, communicate how you will work with your customer in the product design process. I would talk about three areas:

Jobs-to-be-done: Ongoing learning about the different things customers seek to accomplish, what they rank as most important and their level of satisfaction with achieving those goals. This is a deeper dive into motivations, how outcomes will be measured and current pain points.

Ideas: As the most active users of your product (often more than you), customers will see opportunities for improvement. Maintain a site for ongoing suggestions as they occur, and run targeted ideation campaigns for specific areas of development.

Design feedback: Prior to committing to production of a product, run several designs by them. The designs will emphasize different functions and looks, and customers give an early read on how they will be received.

The combination of themes and the ways you’ll work with customers answers the key questions they have. It actually goes way beyond the normal roadmap, providing philosophical underpinnings for your product. And for the product manager, it’s something you can discuss with integrity and enjoyment.

I’m @bhc3 on Twitter.

Filed under mba Tagged with b2b, customer centricity, enterprise software, jobs to be done, product management, roadmap

Prescribing Success with Disruptive Innovation

February 3, 2014 by michaelmayers25 10 Comments

This is a guest post by Michael Mayers, an experienced innovation & new product development leader who has launched successful products in financial services, marketing services and health & wellness. He tweets about innovation, entrepreneurship, and the joy of being a Brit in NYC at @mikemayers25.

At the time of writing Amazon lists 932 books released in the past 90 days under “innovation.” Many of these will espouse a theory of one sort or another that seeks to systematize the process of successfully bringing new products to market. And while most will deliver a superficially cogent model for the limited historic cases provided, nearly all of them will fail to deliver a prescription for future success that works in practice. (That’s right Stage Gate, I’m looking at you!)

Innovators Solution

But some time-tested theories do have prescriptive value. In this blog post I take one such canonical model – Professor Clayton Christensen’stheory of Disruptive Innovation – and use three of its defining characteristics to help identify entrepreneurial opportunities and kick-start successful innovation strategy.

Look for 5 blade razors.

As markets mature industry leaders seek to capture increasing value from their best customers in an effort to drive profitable growth. M&A aside this is typically achieved through the development of incremental, sustaining innovations – a process which most businesses become adept at executing. The inevitable challenge comes when the pace of these innovations oversupply product performance for even the best and most demanding customers. This oversupply, easily measured, is a key indicator that a sector is ripe for disruption.

This tendency is surely no more obvious than Gillette’s flagship razor; the Fusion ProGlide with its parody-inducing 5 blades. Arguably the maximal desired performance from the humble safety razor was surpassed decades ago with the twin-blade Trac II and the addition of a lubricating strip.

Enter Dollar Shave Club who, in 2011, recognized this performance oversupply and launched an innovative business model to attack the razor blade industry’s most over-served customers. It’s first offering was a twin-blade razor – 70s “technology” in blade terms – sold online via a monthly subscription model at a fraction of the price of its big brand competitors. And the attack plan is working: The company raised $12MM in a Series B financing in October last year.

Ignore the best customers.

Take an industry’s best customers – those premium, big ticket whales with the eye-watering margins – and forget about them. Successful disruptive innovations typically target current category low-end or non-consumers, and for two very good reasons:

Firstly, when a new entrant targets non-consumption the competitive response from industry incumbents is often muted to the extent that they may be ignored altogether; just as the personal computer industry was by mainframe manufacturers in the 1980s. And if the interloper seeks to serve and incumbent’s low-end, low-margin customers they may even be happy to give up that pesky, profit-dilutive segment in the pursuit of better financial ratios; just as US car manufacturers gave way to Toyota in the 1980s in the compact economy segment. And let’s face it, who wanted to sell low-margin compacts like the Corolla when you’ve earned the right to sell the S-Class?

Secondly, the initial performance of new technologies usually fall short of the demands of an industry’s best and most sophisticated customers: PC performance was a joke for mainframe computer buyers. Either way a new entrant attack on an industry’s best customers is ill-advised. Either a crippling competitive response or sophisticated customer demands will bring the upstart to its knees. Much better to compete for low-end markets or outright non-consumption where your product can be the best alternative to nothing at all.

Classic examples of this approach include Sony who offered a generation of new consumers access to personal, portable transistor radios while RCA doggedly stuck to heavy vacuum tube technology which afforded significantly better sound quality for the most discerning customer. Or Nucor’s electric arc furnace, suitable only for the production of rebar at its outset, versus Armco’s integrated steel mills which produced much higher grade sheet steel. Or Netflix’s streaming DVDs, utterly at the mercy of fickle bandwidth issues in those early days, versus Blockbuster’s DVD rental business with its significantly higher fidelity picture quality.

When each of these technologies first launched they did not satisfy the current needs of their industry’s best customers. Crucially – and fatally for the businesses who ignored them – each quickly shed their growing pains and enjoyed a higher performance gradient over time than existing ones. The consequence? Having established a beachhead amongst non- or low-end consumers those nascent technologies intercepted and then surpassed the performance of prior technologies. Each successively picked off “low-value” customer segments from the bottom up until they adequately addressed the performance requirements of the entire market. And it’s worth noting that Dollar Shave Club now offer 4- and 6-blade razor lines on their subscription model: The move upmarket has begun.

Understand why the product is hired.

Why did you hire that non-fat latte you had this morning? It’s an odd turn of phrase but you did, in a sense, hire it to do some jobs. Maybe it was to give you a boost of energy. Or to stave off hunger pangs until lunch. Perhaps it was just a useful distraction or a focal point around which to socialize with colleagues. Maybe it was all of those things. Once you accept that we hire products and services to perform “jobs-to-be-done” (JTBD) on functional, emotional and social dimensions a whole world of insight will open up about consumer motivations and the building blocks of competition and product performance from the consumer perspective.

The story of Febreze illustrates this well.[1] Now a $1B product Febreze was very nearly a total failure for P&G. Functionally, it performs an obvious JTBD: It neutralizes odors in household fabrics. Early marketing efforts focussed heavily on this performance dimension but sales were muted. Both the R&D and marketing teams were bewildered as to why such an obviously useful product was failing to gain traction.

Post-launch research highlighted an interesting but troubling phenomenon: Customers were often desensitized and oblivious to even the most pungent odors in their own homes. Functionally, Febreze solved an issue for a home’s visitors rather than its owners.

But the P&G team had a stroke of luck: They observed a few customers who, having worked hard to clean their homes, were then liberally applying Febreze with a final flourish. Diving deeper into this behavior the researchers found that some customers were hiring the product to provide a visceral emotional reward at the end of a period of cleaning – a means to enhance the satisfaction of having a cleaned a room. The penny dropped and Febreze was quickly repositioned for its emotive, rather than functional, qualities and sales soared.

This story is often positioned as a flash of marketing positioning brilliance; a Eureka! moment that’s difficult to replicate. But when viewed through the lens of JTBD it becomes clear that a more systematic understanding of the emotional dimensions to cleaning a home may have saved P&G from considerable heartache. And while Febreze is now a roaring success one has to wonder how many potential category killers have been pulled from the market for want of a better understanding of what the customer was actually trying to achieve?

Flip the coin.

I’ve been looking at this in terms of using the Disruptive Innovation framework to find innovation opportunities. However, if you are an enterprise manager working in an established industry then you can easily turn this around to find corresponding threats. Ask yourself whether you are oversupplying your customers and delivering your own version of the 5 blade razor. For a moment, put your best customers out of your mind and think about how traditional non-consumers and low-end markets might be better served by competing technologies. And put the product marketing brochures to one side and ask what jobs to be done you satisfying amongst your customer base. And finally, if and when you identify a threat or technology that is picking off your least profitable customers, don’t flee upmarket: Stand, fight and innovate right back.

[1] This story is recounted from “The Power of Habit: Why We Do What We Do in Life and Business” by Charles Duhigg.

Filed under mba Tagged with disruptive innovation, innovation, innovator's dilemma, jobs to be done

Decision flow for customer feature requests

January 28, 2014 by Hutch Carpenter 10 Comments

If you manage a product or service in the business-to-business (B2B) market, customer requests for features will be a regular part of your work. Requests come in through the sales team, service reps, and senior management, as well as directly from customers themselves. It’s a disruptive insertion of new items for your agenda. That disruption isn’t necessarily bad, but it does distract you from other planning and execution you’re working on.

Reflecting on my own experiences here, I realized that each request needs to go through a series of decisions. These decisions make sure you know why you would agree to or decline the request, and are aware of the bigger picture effects of your decision. They make up the customer request decision flow:

The flow is a series of decisions, in priority order. My perspective is product management, but they apply to other areas as well (service, contracting processes, etc.).

Firm request from a priority customer?

This decision point is made up of two criteria: priority customer and firm request.

Priority customer

The first decision point may be somewhat offputting, especially if you operate in the small business or consumer markets. It matters who makes the request. In the enterprise market, just a few customers will be a significant share of your revenue. These customers’ revenue help you meet the payroll. They help keep the lights on. If you’re public, they help keep the stock price up.

In addition to high revenue, some customers are also valuable for non-monetary reasons. Lighthouse customers are important for establishing credibility with other companies.

Whether based on revenue or marketing value, some companies will be priority customers. They are a reality in every B2B company. Keeping them happy is part of the job.

Firm request

Sometimes a request is urgent, and vitally important to the customer. Other times, it’s merely a suggestion, a minor nit or a fleeting idea. It’s important to understand the difference.

Firm requests often come freighted with emotional terms, or subtle threats. “We really need this to make sure our sponsors continue to support you.” When they’re firm, pay attention, immediately.

Not all requests are firm. The customer may couch the request with wiggle room. Or directly say “it’s not a big deal”. Often, they have bigger things they want to tackle (on the product, on processes, on strategy) and look at their request as a suggestion-in-passing. They will move on to the bigger items and not focus on the request.

The ability to recognize the difference gets better with experience.

Multiple similar requests?

If the request is not a firm one from a priority customer, the next decision point is: are multiple customers are asking for the same feature? What the request lacks in priority, it may make up in commonality. If customers are making multiple requests for a similar feature, you’ve got a pain point on your hands that needs to be addressed.

A key issue is this: how do you know multiple customers have the same request? A common way is to utilize software which allows customers to post ideas, suggestions and requests. There are idea management providers that are good for this. Or you can user customer feedback sites. These asynchronous, always-on, open-to-all sites are well-suited for capturing suggestions.

In addition, you may need to check other areas. Bad as it is, your email often contains customer suggestions. Or you have a service ticket database you can check. Relevant knowledge will be in people’s heads, those who directly work with customers.

Once you know where to look, the process of determining commonality has two steps:

Identify all similar requests that have been made by different customers
Find all signals of support from customers

If you’re using an ideas or feedback site, finding similar requests is easier. Search on terms that relate to the request. Also, look at the ‘Likes’ and comments the suggestions have. I look at the number of companies represented in these signals of interest.

After gathering this information, you will have a sense of how wide the support is for the suggestion. If it’s sufficient, consider adding the request to your roadmap.

Meaningfully enhances outcomes?

Assume that the request is not a firm one from a priority customer, or one that has yet to be shared by multiple customers. There’s one final decision point: will the suggested feature meaningfully enhance customers’ outcomes?

Outcomes has a specific meaning here. It is the definition of when a job task has been satisfied. It should reflect the customer’s expectations. Remember, they only agree to use (and pay for) your product because you’re making them successful.

To apply this criteria effectively, you need working knowledge of what customers want to get done, and where they’re falling short. If you can see that the request will improve outcomes for a significant number of customers, it should be addressed.

Committed to maintaining feature?

For each of the previous three decision points, if the answer is ‘yes’, there is one more decision to make. Are you committed to maintaining the feature? While this may seem like a simple enough question, there are a number of considerations to it. Below are six factors to consider before answering ‘yes’.

Economics: What are the costs to build and maintain the feature? The expected upside of the feature should cover these. Upside is a holistic concept, including money for the new feature, new sales contracts and renewals because of the feature and increased customer satisfaction that translates into informal marketing for your company.

Release velocity: Every new feature added to a product increases the complexity of future releases. In software, a given configuration can have ongoing downstream impacts. Yammer’s V:P Engineering Kris Gale sees the additional complexity as a tax on product velocity. Your ability to release quality products quickly is impacted with each new feature. It’s worth it to add features, but think carefully about velocity impact.

User experience: The ability to use the product or service effectively is a core requirement for customers. If they find that it too complex, they will not fulfill their jobs-to-be-done. Joshua Porter nice summarizes the issue of feature creep: “No single feature addition is a big deal, but taken together change everything.” The value of the request must be greater than any negative effects on user experience.

Tip of the iceberg: sometimes, a request is a “jump” from the current product or service. And it’s only part of a broader offering needed to really address the need. You can look at a request and see how additional features will be needed over time to make it deliver value. And that may take the product in a direction you don’t want to go. Understand the longer term plan related to the request.

Mass market: You’re building a product or service for the mass market. It needs to address a large swath of customers’ needs. In that light, look at the current request. Is it the umpteenth time that this customer, or one of a handful of customers have requested something? Too many ‘outside-the-market’ requests can undermine your broader strategy. You win the battle for the lighthouse customer, but lose the war with the broader market.

Outcome prioritization: Smart product management is organized according to customers’ jobs-to-be-done and expected outcomes. Some outcomes may be currently underserved. Customers’ expectations are being met, and that needs to be addressed. The new request will delay the implementation of features to address these outstanding pain points. Determine if the new request outweighs the currently underserved outcomes.

Decide on the request

Decline the request

If the request cannot cleanly get through the six criteria of the “Committed to maintaining feature?” decision point, it is reasonable to decline the request. Indeed, you now have specific reasons for doing so. That alone is a big improvement versus what often happens: the request sits in the equivalent of a “dead letter” file. Or if there is a response, there’s only a vague, “we can’t do that right now.”

Address the request

If the request makes sense, then it’s full steam ahead. However, notice I’ve used the term “address the request”. This is different than “implement the request”. Maintain a philosophy that:

Customers know their jobs-to-be-done better than you, but you will know potential solutions better than them.

Not to say the customer hasn’t provided a specific feature solution that is right. But avoid just passing through exactly what what was requested without giving thought to different ways the job-to-be-done can be addressed.

Customer requests will be a constant in the B2B product manager’s life. Knowing how you’re going to handle them is key to the success of the product and the business.

I’m @bhc3 on Twitter.

Filed under mba Tagged with b2b, customer needs, enterprise software, jobs to be done, lighthouse customers, product management, voc

Collecting and analyzing jobs-to-be-done

January 13, 2014 by Hutch Carpenter 9 Comments

via the Daily Mail

I’ve previously written about collecting jobs-to-be-done from customers. Because I was analyzing a broad topic across the entire innovation lifecycle, it was a good way to get a breadth of insight. However, it doesn’t work as well in the more common situation for product managers and innovators: analyzing a specific flow. In that case, there are three requirements for collecting jobs-to-be-done:

Comprehensive capture of job elements
Map collection as closely as possible to the actual job flow
Understand importance and satisfaction of individual tasks

Comprehensive is important, because you can’t address what you don’t know. A limitation of my previous effort was that it was not comprehensive. Actual job flow is a powerful framework. Needs captured in context are more valuable, and it’s critical to follow the steps in the job. Importance and satisfaction become the basis for prioritizing effort.

To address these requirements, I’ve put together a process to understand customers’ jobs-to-be-done. The major elements are:

For purposes of this write-up, assume you’re an automotive product manager. You’re tasked with understanding people’s needs to get work done on the commute to the office. Note this is a job that becomes more readily enabled by self-driving cars.

Start with the job flow

A job-to-be-done has a flow. For example, take this job:

When I commute to the office, I want to get work done.

A job flow consists of the job’s major activities, in sequence. The job flow looks something like this:

The purpose of the flow is to provide a framework for capturing specific tasks. Putting this together is primarily the responsibility of the product manager (or innovation team). By stating the major activities that define the job, expect a much more comprehensive capture of all the job elements.

Job task

Each activity consists of a series of tasks. Task are what the customer actually does. They are independent of specific features, although may often be intertwined. Here’s an example task:

Previously, I’d focused on including context in job statements. But when these tasks are organized according to the job flow, the context is readily known. So task statements don’t include a context element.

But they do include an expectation statement. For every task we do, we have an expectation for it. It defines whether we consider the current experience wonderful or painful. This expectation is formalized for each task, captured in the customer’s own words. It’s valuable to know what the customer expects, as that becomes the basis of design.

Collect jobs tasks for each activity

Next step is to conduct the actual customer interviews. Whether done in the customer’s environment (best) or via a web conference call (acceptable), the job flow provides a familiar framework to the customer.

When I worked at eFinance, I conducted brown paper sessions with clients to understand their commercial credit processes. A staple of the Capgemini consulting model, the brown paper is a step-by-step process flow of what the customer does today. Collecting the job tasks is similar here. Similarities and differences:

Brown papers are conducted with groups of people together. Job-to-be-done capture will more often be solo interviews.
Brown papers are done in a strict step-by-step flow, captured visually on a wall. If doing this for job-to-be-done interviews works for you, go for it. But a simpler post-it note capture style works as well.
After capturing the steps in a brown paper, the group is invited to post stickies describing points where improvement is needed. In the job-to-be-done interviews, each task includes a statement of what the customer expects for it.

A key element of the interview process is to probe the responses of the customer. In a perfect world, they will lay out the individual tasks and easily express their expectations. But likely, customers will talk a lot about features. Which is valuable in its own right. But the objective here is to capture what they are trying to get done. So apply the simple question why. Not in a robotic way. But make sure to probe past the expression of features. These are the tasks – versus features – to place on the job canvas.

Here’s an example of the approach:

Customer: I want a 4G internet card.
Interviewer: Why do you need that?
Customer: So I can connect to email and the web.
Interviewer: What is your expectation for connecting to email and the web?
Customer: Always-on internet.

One tip: Use different color sticky notes for each major activity’s group of tasks. This color coding will help later in identifying where the tasks occur in the job flow.

Job canvas

For each major activity, job tasks are collected onto that customer’s job canvas. An example (with fewer tasks than would actually be there):

In reality, there will be a large number of tasks per customer interviewed. Strategyn’s Tony Ulwick states there will be between 50-150 outcomes collected from multiple customer interviews. Gerry Katz of Applied Marketing Science sees 100 or more needs collected as well. Sheila Mello of Product Development Consulting says it’s not unusual to extra several hundred images from the customer interviews.

Top tasks by importance and dissatisfaction

Once the job tasks have been captured, the customer selects the tasks:

That are most important
That are least satisfied

The customer will select the 3-5 tasks that are most important for each major activity in the flow (e.g. there are 3 major activities shown in the job canvas above). These tasks will be assigned points. For example, assume three tasks are identified as important. The most important task would receive 3 points, the next most important 2 points, and so on.

The customer will also select the 3-5 tasks that are least satisfied for each major activity in the flow. Assuming three selected tasks, the task that is least satisfied receives 3 points, the next least satisfied task receives 2 points, and so on.

Keep this insight handy, but separate from the collected stickies (or however you’ve collected the job tasks). We’ll come back to how to use this information.

Note: it will help to apply unique numbers to the individual job tasks. You’re going to want to know the most important and least satisfied tasks across multiple customers later in the process.

Number of customer interviews

A general rule of thumb is that 15-20 customer interviews will provides solid coverage of customers’ needs. You can take it further, as George Castellion advocates 40 interviews. Each interview starts with a blank canvas containing only major activities.

Create affinity groups

After conducting multiple interviews, you will have a large number of job tasks, with information on which ones are most important and least satisfied. Working with a large number of statements by people is a challenge that others have faced. They key is to reduce the large number to a manageable set of insights. There’s a proven approach called the KJ-Method to systematically abstract hundreds of statements into a few key groups.

UX expert Jared Spool provides a detailed series of steps to run the K-J Method. I’ll use his description here.

Bring together group of people do the affinity grouping

The first step is to determine who will do the affinity grouping with you. Try to keep this group at 5 people or fewer. Draw on people from different disciplines.

Put all the job tasks on a wall

In a single space, all the job tasks should be visible and accessible. They need not be laid out in the job flow, which might introduce a bias to the grouping. The color of the stickies will be the basis for knowing where the tasks fall in the flow.

Group similar items

The next step is for the team members to group like job tasks together. The process is one of looking at pairs of tasks, and determining if they share characteristics. This how Jared instructs clients to do this:

“Take two items that seem like they belong together and place them in an empty portion of the wall, at least 2 feet away from any other sticky notes. Then keep moving other like items into that group.”

“Feel free to move items into groups other people create. If, when reviewing someone else’s group, it doesn’t quite make sense to you, please feel free to rearrange the items until the grouping makes sense.”

“You’re to complete this step without any discussion of the sticky notes or the groups. Every item has to be in a group, though there are likely to be a few groups with only one item.”

Label the groups

Each participant then gets to label each group. This entails looking at the grouped job tasks and determining the common theme. Again, here’s how Jared instructs teams on this process:

“I want you to now give each group a name. Read through each group and write down a name that best represents each group on the new set of sticky notes I just gave you.”

“A name is a noun cluster, such as ‘Printer Support Problems’. Please refrain from writing entire sentences.”

“As you read through each group, you may realize that the group really has two themes. Feel free to split those groups up, as appropriate.”

“You may also notice that two groups really share the same theme. In that case, you can feel free to combine the two groups into one.”

“Please give every group a name. A group can have more than one name. The only time you’re excused from giving a group a name is if someone has already used the exact words you had intended to use.”

Note that part of the exercise in this step is to give one more consideration to the groupings. If, upon trying to determine a label one finds that the groups doesn’t actually make sense, the groups can be split up as needed.

I’ll add this caveat to Jared’s instructions. For purposes of this affinity group work, lots of different labels for each group of tasks are not important. It’s OK to go with one person’s good label for a group, a point to emphasize more strongly.

Here’s an example of labeling a group of job tasks:

Once done, you’ve organized a solid group of job tasks into major themes for what customers are trying to do.

Calculate the importance and dissatisfaction score for each group

Remember asking the customers to rate the three most important and three least satisfied job tasks? Now it’s time to use those ratings. In each group, calculate the following for both importance and dissatisfaction:

Total points
Average points per task

For each group, you’ll have something like this:

The Total score gives a sense for where the customer energy is. Large scores on either metric will demand attention. The Average score is good for cases where a group has only a few, highly scored job tasks. It ensures they don’t get overlooked.

Prioritize roadmap

You now have major groups scored with customers’ view of importance and dissatisfaction. Within each group are the tasks and expectations that customers have. This is the good stuff, the insight that fuels design efforts. It’s also the data-driven, factually based input that helps clear the fog when tackling a new area for development.

The expressed customer insight – what they want to do, what is important, what is not satisfied – becomes the foundation for constructing a roadmap. The team can layer on other considerations: business strategy, adjacent initiatives that impact the effort, internal priorities. Balance these with what customers actually value. Anything that ignores this hard-won customer insight needs a compelling reason, and an understanding of the higher risk it entails.

I’m @bhc3 on Twitter.

Filed under mba Tagged with brown paper, capgemini, customer insights, customer interviews, customer needs, jobs to be done, jtbd, self-driving cars, voice of the customer

The Folly of Inside-Out Product Thinking

December 12, 2013 by Hutch Carpenter 2 Comments

Inside out just doesn’t fit right

Ever run into this deductive reasoning?

Customers like our existing products and our company
We are building a new product that reflects the priorities of a company executive
Therefore, customers will like our new product

It’s a clear violation of the First Law of Product: Customers decide what products they like, not companies.

Inside-out thinking is a situation where the wrong reasons are applied to decide which products are to be developed:

That market is so big, let’s build something for it
My intuition says this is the next big thing
This new product will position our company for what is important to us

Those reasons are actually not entirely out of the question for success either. The things that define truly inside-out thinking are (i) an impulse guided by a “we need” , not a “the customer needs” mentality; and (ii) skipping customer validation or ignoring troubling feedback from customers during validation. When you see those two dynamics at play, you’ve left the realm of sophisticated decision-making. You’re in the land of gambling with shareholders’ money. Sure, some inside-out products will succeed. But that’s analogous to saying that some lottery ticket holders win too. It’s a sucker’s bet.

Inside-out thinking is a pervasive thing. I came across this table in Gerry McGovern’s book, The Stranger’s Long Neck. McGovern surveyed SMB users of a website Microsoft runs – Pinpoint – that helps find IT solutions built on Microsoft technologies. The SMBs were asked what their top tasks were when they visited Pinpoint. McGovern then did something interesting: he asked the Microsoft team what they thought users’ top tasks were.

The table below outlines the results:

Customer	Microsoft
Internet security	Customer relationship management
Backup and recovery	Internet marketing
Security	Network management
Desktop support	Sales/lead generation
Data/document management	Billing

That’s a stark difference between what users value and what Microsoft thought they did. Or perhaps what Microsoft wished users valued. As McGovern notes, “And just like every other organization on the planet, what Microsoft wants is not always what the customer wants.”

This isn’t to pick on Microsoft; it really is the case at companies everywhere. Microsoft just happens to have been open enough to share their own experience here.

You can recognize it when it happens. Here are the Top 3 signs of inside-out thinking:

The spreadsheet says it will be big!
I don’t need customer validation, they don’t know what they want anyway
The Board/CEO/other senior executive is pressuring us to do this

Inside-out thinking is poor decision-making, it’s a bet with terrible odds, and wastes resources. Tough to understand how we can be so methodical with other operations in the organization and still go seat-of-the-pants in this area.

Update: I hadn’t seen his tweet at the time I published this post, but Box founder/CEO Aaron Levie offers another consequence of inside-out thinking here:

The easiest software incumbent to disrupt is the one prioritizing the needs of its strategy over the needs of its customer.

— Aaron Levie (@levie) December 12, 2013

I’m @bhc3 on Twitter.

Filed under mba Tagged with customer development, customer validation, Gerry McGovern, innovation, inside-out, jobs to be done, microsoft, product management

The Product Manager is the Chief Customer Development Officer

December 5, 2013 by Hutch Carpenter 4 Comments

If pressed, what would you say is the secret to product success? Certainly there are a number of things that go into making and selling products. Prioritization, design, manufacturing frameworks, marketing, service, cost of production, etc. Each of these elements needs to be optimized, and there are people, practices and tools that do just that.

Despite rigor in much of the product process, there’s still too high a failure rate for products. I’ll bet you’ve seen this in your own company: proposed products that received a lot of internal resources only to be killed off, or that launched and didn’t hit the mark with customers. As you can see, there’s a story to it:

Consider that first panel for a moment. A third of launched products fail. That doesn’t include the projects that were killed before launch. 32% of development resources are spent on products that get scrapped or fail in the market. To put that in perspective, imagine similar levels of failure in other venues:

We miscalculated 32% of the accounting entries
32% of our inventory purchases were wasted
Our marketing initiatives fail to sell anything or raise brand awareness 32% of the time
32% of our manufacturing capacity is chronically unavailable

Those levels of performance would be unacceptable in companies. Yet they’re considered part of the ‘art’ of innovation when it comes to product. The cost of doing business. Which is pretty sweet if you’re a product person…

OK, forget that. Let’s assume rational, ambitious people want to do better.

What works? Survey says…

In a survey of B2B firms, people were asked to identify the causes of failed products. The top answer was ‘lack of market analysis’. As in, did the market have the need, did the feature address it if so, and did it do so better than competing products? The next answer was that the ‘product didn’t satisfy customer needs’. There’s a pattern here.

Flip the analysis…what are the top success factors? All three are specifically rooted in understanding customer needs:

Product directed at customer needs
Staying close to the customer
Product adds value to the customer

Notice that pattern again? Products that succeed are designed and developed with customer insight.

Factors that make customer involvement successful

Researchers in Sweden conducted an analysis of firms’ product development efforts, classifying the products as successful or not successful. They tracked these product outcomes against the types of interactions the firms have with customers. Note they tracked product development efforts as incremental innovation. They separately tracked radical innovations as well.

For incremental innovation – i.e. the daily work of product managers – they were able to identify three factors that separated successful products from the rest. Factors that affected the “absorptive capacity” of the company to assimilate customer needs.

Engagement frequency: The more often a company communicates with customers, the more successful were it product releases. Communication can be oriented toward understanding needs, or for feedback on design iterations.

Two-way communication: The nature of the communication dictates its value. If the company does all the talking, it’s not going to learn much. The more the communication is a dialogue, the better the outcome for the product.

Needs in context: The more the insight is captured as part of a broader view of the activity, the better that insight is. Top insight is gathered as the customer experiences using the product. It’s also valuable to understand the why for insight. If the suggestion or need is in isolation, it can be hard to understand the core need.

Now, who is in charge of getting this insight?

Chief Customer Development Officer

Think about this. For marketing, it’s clear who owns that activity, and you can see processes, systems, people and priorities for it. Same goes for manufacturing / development. And design. And supply chain management. And distribution. And financial analysis. And human resources. And so on…

But where are the comparable processes and people dedicated to understanding the customers’ needs? Who plumbs the jobs-to-be-done and analyzes the key outcomes customers are seeking? The work of understanding customer needs, in one sense, is everybody’s responsibility. It’s what makes the company grow. But if something is everybody’s responsibility, it’s really nobody’s responsibility.

It’s an important question, because the degree to which one stays close to the customer is a primary basis of success or failure in product development. As a function, what would you call this work? Customer Needs Whisperer? Voice of the Customer-ologist? Actually, Steve Blank has it covered with customer development:

Before any of the traditional functions of selling and marketing can happen, the company has to prove a market could exist, verify someone would pay real dollars for the solutions the company envisions, and then go out and create the market. These testing, learning and discovery activities are at the heart of what makes a startup unique, and they are what make Customer Development so different from the Product Development process

Steve Blank, The Four Steps to the Epiphany

While Steve Blank’s excellent book is targeted at entrepreneurs who need to do the hard work of validating an idea, the mindset underlying customer development is well-suited for the need to stay close to customers. Hence, the notion of the Chief Customer Development Officer. And the product management team sits at ground zero in the customer development activity.

What distinguishes customer development from the current mentality in most companies? Cribbing from a Jack London quote:

You can’t wait for customer insight to come to you. You have to go after it with a club.

This is a change in mindset for many. Be proactive in understanding customers. Make communicating with customers a meaningful percentage of the weekly schedule. Don’t settle for inbound inquiries. Or only focus groups on an already-designed product. Or quarterly customer council meetings. Really own the customer development activity.

It’s worth it, as here are five concrete benefits of employing the customer development mindset:

Develop understanding of what success looks like for the customer
Customer becomes invested in the success of the product
Elevate customers’ awareness of what’s coming
Discover opportunities for growth due to underserved JTBD
Reduce uncertainty due to lack of information

You only get these by being a proactive customer development officer. In a future post, I’ll examine the different ways engage customers in the product development process. Because there are many.

I’m @bhc3 on Twitter.

Filed under mba Tagged with customer development, jobs to be done, jtbd

10 examples of fabulously flawed product-first thinking

November 5, 2013 by Hutch Carpenter 9 Comments

In talking about jobs-to-be-done here, I sometimes think that all I’m doing is stating the obvious. I mean, isn’t it obvious that you’d create something that helped fulfill a need or desire? What else would you do?

But I’ve seen in my own work experience, and across a multitude of initiatives in other industries, cases where that’s not necessarily the case. Invention was the thing. I mean that in this sense:

Invention creates. Innovation changes.

Exercising creative chops was the focus, with a thought that customers would have to take up this amazing thing invented. But unfortunately, that’s not generally the case. The invention is not adopted, and thus nothing changes for the target market. Innovation does not occur. The invention either does not address a job-to-be-done or the proposed solution was nowhere near satisfying the specific outcomes of an applicable job-to-be-done.

To illuminate how this “product-first” dynamic is a pervasive dynamic, I’ve collected ten examples of it. While the plural of anecdote is not data, see if you recognize similar examples in your own experience.

1. Because Apple, Microsoft, Google did it!

Context

Kareem Mayan wrote a great post Why only fools write code first. In it, he stated, “I have a confession to make: I’m 35, and until last year, I started building companies by creating a product.” The post describes on his evolution in thinking, focusing first on customer needs before building anything.

Product-first thinking

In the comments, someone wrote:

“Almost all of the successful startups I know of built a product first, simply because the founder wanted. Apple, Microsoft, Google, Dropbox — some of these are famous even today for never doing user surveys.”

This argument expressed skepticism about Kareem’s point.

Analysis

A good example of the ongoing pervasiveness of product-first thinking. It really is everywhere. Here, the commenter displays a classic example of the survivor bias. A focus on only those companies that made it, and what they do. Ignoring that perhaps dozens of competitors also charged ahead with their own product-first approaches. And were nowhere near as successful.

It’s like looking at the ways lottery winners live, and saying that’s the way you should live too. They’re not connected.

Of course, it’s also possible the commenter actually has no idea what those companies do in terms of understanding customer needs…

2. The “what you can do for us” attitude

Yahoo home page 2002, via All Things D

Context

Way before Marissa Mayer joined Yahoo, the company was a case study in mediocrity. From its glory days in the 90s, it had managed to become a bloated collection of media properties, without a coherent strategy due to a succession of changing executives and business models.

Product-first thinking

As reported by Kara Swisher on All Things D, Yahoo’s home page became increasingly overrun with links. To cram more stuff above-the-fold, font sizes shrunk. It became a nasty hodge podge of links that no longer related to what users wanted.

As Yahoo’s Tapan Bhat, SVP of Integrated Consumer Experiences noted, “It had nothing to do with the user, but what Yahoo wanted the user to do.”

Analysis

What Yahoo wanted the user to. What a wonderful expression of the approach. It’s such a pernicious mode, where the needs of the company eclipse those of the customers. Call it inside-out thinking. When the company’s, not the customers’, needs drive product and service decisions, it’s a good bet customers will turn elsewhere. It’s a great opportunity for competitors.

3. Dazzled by the invention

Source: NBC Bay Area

Context

Anyone remember the hype over Dean Kamen’s project code named Ginger back in 2001? Turned out to be the Segway, that amazing triumph of technology that allowed people to travel on a motorized two-wheel scooter. It really is amazing, with its self-balancing mechanism, easy navigation and smooth ride.

Product-first thinking

It was hailed as the next coming of great technology. No really, it was. Here are quotes by both Steve Jobs and Jeff Bezos prior to its launch:

Jobs: “If enough people see this machine, you won’t have to convince them to architect cities around it; it’ll just happen.” (#)

Bezos: “You have a product so revolutionary, you’ll have no problem selling it.” (#)

Wow! So what happened? Well, have you taken your Segway out for a spin today? It missed the mark in terms of how frequent the job-to-be-done was. For me, Segways are what tourists rent to travel around Golden Gate Park in San Francisco.

Analysis

My own perspective is that Segway is an optimum mode of transport for journeys where walking would take more than 10 minutes and less than 30. And where you don’t need to carry anything heavy or bulky. And where weather would be OK for the journey. Steve Jobs, who did heap praise on it, was prescient about what needs it didn’t fill.

“Jobs said he lived seven minutes from a grocery and wasn’t sure he would use Ginger to get there. Bezos agreed.” (#)

So Jobs and Bezos were full of praise, but in a hard analysis couldn’t quite say what mass job-to-be-done the Segway fulfilled. And it turns out most of the market couldn’t either. Sometimes the invention is so dazzling, we’re blinded to understanding what need it actually fulfills. Invention first thinking.

4. Same template, different market

Via Bloomberg Business Week

Context

Ron Johnson did a fantastic job of creating the Apple stores. They’re enjoyable to visit, full of all the latest in cool technology Apple has to offer. The clean vibe, the on-the-spot purchasing, the Genius Bar. Clearly he brought some of the experience from his Target (aka “Tar-jay“) days to the job.

Based on this, the Board of JC Penney installed him as CEO to restore a retailer that had lost its luster.

Product-first thinking

Johnson put in place a number of changes to reinvigorate the retailer. He stopped the discounting, going for a low price everyday approach (like Target). He developed brands that would be exclusive to JC Penney (like Target). Trained employees to help people shopping (like Apple).

Ultimately, however, his changes didn’t take. Perhaps the most telling insight came from another executive:

Ron’s response at the time was, just like at Apple, customers don’t always know what they want,” said an executive who advocated testing. “We’re not going to test it — we’re going to roll it out.”

There it is, product-first — or maybe vision-first — thinking.

Analysis

It’s tempting to look at this as the hubris of being smarter than customers. But I don’t think that’s the lesson to draw. Rather, this is a case of previous success with a format in other markets (Target, Apple), and applying it to a new market. Without understanding the customers in the new market. The fact that Johnson didn’t feel the need to run the new strategies by JC Penney’s customer base was due to his success with the template previously. Why test? You know what customers want.

But in this case, it led to overlooking existing customers and what they outcomes were being fulfilled by JC Penney. This alienates the core customer base, while potential new customers ponder why they’d switch from Target to JC Penney. Unsurprisingly, the stock dropped 55% during his tenure, with a horrendous 32% drop in same-store sales in the critical holiday 4th quarter of 2012.

5. Blaze a new trail

Context

Tired of people saying you should listen to the marketplace, Dan Waldschmidt advocates something different. He argues that most of the time, people don’t know what they want. In making his argument, he references both American slavery and Martin Luther’s religious reformation.

Product-first thinking

Here is how Dan puts it:

One of the things business experts tell you when you are considering changes to your sales strategy is the idea that you need to “listen to your marketplace”. That you need to take your idea and run it by the people around you to get some feedback. Instead, blaze a new trail. Think about where you want to lead your market.

Analysis

Perhaps the key phrase is lead your market. That, in and of itself, is fine. Lead your market in sales. In profits. In innovations that resonate. But in the context of (i) ignoring the marketplace; and (ii) blazing a new trail, it comes across as advice to tell the market where it needs to go. Which actually is nice if you can accomplish it. Alas, the business landscape is littered with folks who tried to tell the market where to go. The market can be fickle that way.

To be fair, it is important to separate the jobs-to-be-done from the potential solutions. That’s a better way to think about Dan’s advice.

6. What Steve Jobs said

Via Inc. Magazine, 1989

Context

Perhaps you have seen this quote by Steve Jobs:

“You can’t just ask customers what they want and then try to give that to them.”

Run a search on that exact phrase, and 687,000 results are returned. It’s a sentiment from one of the all-time greats that clearly has caught on.

Product-first thinking

Interpretation is important here. When you read a number of articles that reference the quote, the context is one of divining products that no one in the market would come up with. Use your inner genius to do this. As written about Jobs in Fast Company:

He is a focus group of one, the ideal Apple customer, two years out.

And he was quite good.

Analysis

But for most of us, we’re not an ideal focus group of one. That’d be the dangerous lesson to draw from his quote. If every corporate product person, or innovator, or strategist decided to channel his inner focus group of one, there’d be a lot of wasted resources. Actually, there are a lot of wasted resources

The other thing to note is the quote in its fuller context. Here’s more from Jobs in the 1989 interview with Steve Jobs where he first said that quote:

“You can get into just as much trouble by going into the technology lab and asking your engineers, “OK, what can you do for me today?” That rarely leads to a product that customers want or to one that you’re very proud of building when you get done. You have to merge these points of view, and you have to do it in an interactive way over a period of time—which doesn’t mean a week. It takes a long time to pull out of customers what they really want, and it takes a long time to pull out of technology what it can really give.”

Sound like he’s advocating to ignore your customers?

7. My business model demands your attention

Facebook Home user ratings

Context

A few months ago, Facebook introduced Facebook Home. This app for Android became the user interface of the phone. In so doing, it dominates the experience on the device:

Designed to be a drop-in replacement for the existing home screen (“launcher”) on an Android device, the software provides a replacement home screen that allows users to easily view and post content on Facebook along with launching apps, a replacement lock screen that displays notifications from Facebook and other apps, and an overlay which allows users to chat via Facebook messages or SMS from any app.

Note that the existing Facebook app was still available, allowing you to get your Facebook updates via the phone.

Product-first thinking

What Facebook Home does is elevate Facebook above all others on the phone. It was a play to get Facebook front and center in your daily experience. There would be access to all your other apps, but the path to them would go through Facebook each and every time.

Globally, the average smartphone user has 26 apps on their phone. For Facebook Home to be popular, the typical user would rank Facebook above all other apps. The games. Email. Twitter. Instagram. And on…

Analysis

Ultimately, Facebook Home withered in the market. I can understand why. In 2012, mobile time spent on Facebook surpassed time on the Facebook website. From a user experience perspective, Facebook wanted to make mobile even easier. From an advertising perspective, Facebook needed to establish a way to present more mobile ads. Imagine serving up an ad every time someone turned on their Android phone.

But the problem is that Facebook was solving a job that most users were already satisfied with. The Facebook App works well for its purpose. It also imposed new friction on using one’s mobile device. The burden of navigating through Facebook to get to your other 25 apps. As Joseph Farrell, EVP Operations at BiTE interactive, said:

“Facebook Home solves Facebook’s needs for more user data, but what does it solve for its users?”

8. Solution in search of a problem

Context

In a post, entrepreneur Ramli John talked about lessons he’s learned from failed startup efforts. Specifically, the experience gained with Lesson Sensei. Lesson Sensei didn’t make it.

Product-first thinking

Ramli states plainly the trap he fell into:

“Don’t lose focus of the problem. That was one of the biggest mistake I made in my previous failed startup, Lesson Sensei. About a few weeks in, we realized that we really don’t have a problem to solve. But, we had this awesome solution. So we started pivoting on possible problems we can solve with our solution. Each week, we tried a new problem to solve. Each time, we found a flaw with our assumption. Then, we started losing steam. Always start with validating a problem before you validate the solution. The other way around just takes up too much time and energy.”

Analysis

This is a classic issue. There’s a hazy sense of what an idea could address. It’s not nailed down yet, but there’s the rush of starting on the solution anyway. To be fair, there is some merit in this. You could be 50% there in terms of product-market fit, and the initial product can help elicit the right iterations. But as Ramli notes, that can be an expensive approach. It burns time, energy and money. And depending on how hazy that view is of the actual job-to-be-done and its attendant outcomes, you may be entirely off track.

9. We’ll get to those customers at some point

Context

Robin Chase is the founder and former CEO of Zipcar (acquired by Avis in 2013). After Zipcar, she founded GoLoco, a carpooling app. Unlike Zipcar, GoLoco didn’t make it. She is now leading Buzzcar, a peer-to-peer car sharing service.

Product-first thinking

Robin is open about the failure of GoLoco:

“With my second company, GoLoco – social online ridesharing – we spent too much money on the website and software before engaging with our first customers.”

Analysis

In some ways, this is a similar situation to Ron Johnson at JC Penney. Having been successful in getting Zipcar going, Robin had a confident attitude about her new endeavor. That confidence led her to develop first, worry about customers later. As she notes, this was backwards. The spade work of understanding customers’ needs is a critical first step.

10. Dazzled by the innovator and the hot trends

Context

Remember Color? This app would let you take pictures. These pictures were then visible to anyone with the Color app within 100 feet of you. It was a way for friends or strangers to participate together in some close proximity.

Color is no more. It didn’t fare well.

Product-first thinking

It was a can’t-miss app. It was started by an energetic, persuasive entrepreneur whose previous company was bought by Apple. It was SOcial. It was LOcation-based. It was MObile. It was SoLoMo!

With that combination, Sequoia Capital and Bain Capital felt confident investing $41 million. Product-first thinking.

Analysis

Presumably, the entrepreneur’s previous success was a good-enough proxy for understanding the target market’s jobs-to-be-done and attendant outcomes. However, as seen with GoLoco above, previous success doesn’t automatically grant the ability to divine customer needs. There’s still the work of understanding the market you intend to tackle.

GigaOm’s Darrell Etherington gets props for identifying the flaws of Color right at its launch:

“But I think it’s more likely this is a prime example of how, when it comes to apps, 1+1+1 does not always equal 3. An app can’t just hope to profit by being at the intersection of a number of promising mobile trends. Developers still have to think intelligently about how those trends integrate, and remember that user experience, especially the one following first launch, is still the key to wide app adoption.”

Remember this next time you see another startup in an overhyped space, say Big Data. What job-to-be-done does it fulfill?

Wrap-up

Perhaps not surprisingly given my work experience and interests, these examples have a heavy technology orientation. One can imagine similar cases in financial services, apparel, consumer product goods, etc. Hopefully the examples here will be useful as you look at your own world. And in your own work. I’ll admit to being guilty of product-first thinking. The creative muse is a strong human characteristic. But recognize when that muse is taking you down a path you shouldn’t go.

I’m @bhc3 on Twitter.

Filed under mba Tagged with facebook, innovation, JC Penney, jeff bezos, jobs to be done, jtbd, product management, Segway, steve jobs, yahoo

Uncover latent needs with a simple question

October 31, 2013 by Hutch Carpenter 4 Comments

After publishing Latent needs are overplayed as an innovation dynamic, I got a lot of feedback. Plenty of agreement, but also some good counterpoints. And in reading through some of them, I realized that there is something to this. A lot of people are convinced that whole markets are waiting to be built based on people not really understanding their own needs.

Or if not whole markets, at least new products that can find success based on unrealized needs.

I submit that there is an antidote to this problem. That the issue is not that customers either do not know or cannot articulate their needs, or jobs-to-be-done. It’s that follow-up is required.

Are you asking ‘why’ enough?

The antidote to the scourge of latent needs is simple: ask ‘WHY?”

As you interview a customer, you’re seeking their jobs-to-be-done, along with the associated outcomes that are needed to be successful in that job. Here’s the thing: you’re going to get superficial responses initially. Not because people don’t realize their own needs. Rather, they’re fixated on current processes and product features (this is the ‘faster horses’ issue). We go with what we can recall the easiest. It’s a natural phenomenon, documented well by Daniel Kahneman in his book Thinking, Fast and Slow. But it can result in limited insight into what they really value and seek to accomplish.

When interviewing a customer, listen for your internal voice that says, “this need is not the real one”. You’ll know it, because it will be deeply entwined in the current product features. That’s when delivering a well-timed ‘WHY?’ will make a difference.

This is not a novel concept. Indeed, it’s part of the lean six sigma methodology, used to get at the root cause of issues (here’s a Jeff Bezos example). But it’s perhaps not so obvious to use WHY in the pursuit of latent needs.

I have found asking ‘WHY’ to be a great method for penetrating the “what I easily know” bias. Two examples below – one from a former HPer, one from me – relate the value of understanding ‘WHY’.

HP large format graphic plotter	Spigit innovation management platform
Related by Marvin Patterson, President Dileab Group, and formerly with Hewlett-Packard	From my own experience as VP Product – Spigit
We were asked to figure out how to get HP into the large format graphic plotter business. In one customer visit after another we were told that accuracy was the critical requirement. The current product to beat utilized a magnetic x-y motor moving over a precisely grooved steel surface that was mounted on a super-flat granite slab weighing the better part of a ton. This $50,000 product had accuracy that was hard to beat. During a visit to a semiconductor design company, I asked them to show us how they used these highly accurate drawings. We were ushered into a room where engineers were verifying the design of multiple chip layers. They did this by taping the drawings, each roughly 3×4 meters, to a large light table, with each drawing carefully aligned with the one below. They would then crawl around on top of the light table, literally on their hands and knees, sighting down through the layers of transparent Mylar, and checking the alignment and design of each layer. “See,” said our host, “that’s why we need the accuracy.” But, in fact, this application did not use the accuracy at all. It depended, instead, only on repeatability between one drawing and the next. Repeatability is fairly cheap and easy to accomplish. Accuracy is really, really expensive. After a thorough survey of the market, we decided that repeatability was the crucial specification in most applications, so we traded off accuracy for lower cost. The resulting product employed a radical new plotting mechanism that delivered extremely good repeatability, fairly poor accuracy, and sold for under $15,000. Within three years its sales exceeded 50% market share.	I performed a jobs-to-be-done exercise with multiple customers. One job that several talked about was the need to get more people ‘down-voting’ ideas. What they were seeing was that people tended to be positive only, or they didn’t rate an idea at all. Hence the desire for more down-votes. But I asked for more than that. “Why?” Because they wanted better distinguishing of the good ideas from the bad, and getting only up-votes made that hard.The real need was better ways to distinguish ideas. The request for ways to increase down votes was the way they expressed that.Customers were providing feedback on the current process/features when they talked about more down-votes. But pressing them to understand why unveiled the real need. And there are a lot of other ways to stratify ideas besides increasing down-votes.
Marvin got to the real need here by pursuing customers’ responses through ‘why’. Note that repeatability wasn’t an unrealized need. Customers were doing this with every design! They indeed realized they needed to do it. It’s just that they were caught up in the current process they used when expressing	This insight was used later in the product roadmap to address the real need. Rather than push to get users to do something they were uncomfortable with – down voting – there are ways to leverage what they actually do.

In both cases, customers were providing feedback about current process and product features. But with some digging, the root job-to-be-done was secured. Nothing latent or unrealized. Just some work penetrating the natural way people think: starting with what they can easily recall. Dig deeper with WHY.

I’m @bhc3 on Twitter.

Filed under mba Tagged with jobs to be done, jtbd, latent needs

Tell your work story with an infographic

October 28, 2013 by Hutch Carpenter 8 Comments

I have recently found myself updating my resume. Why? After 4 1/2 years at Spigit, I have moved on as the company has been acquired by Mindjet. It was a good run there.

So I needed to dust off the resume. And you know, it was eye-opening how limiting resumes are. They are great for their core job-to-be-done: provide a history of your work. But they’re terrible if you want to go into more depth. You see advice to limit resumes to two pages. Use “power” verbs. Avoid graphics that foul up automatic scanners. Good counsel, but not what I want.

I wanted to communicate a narrative about my work at Spigit. We spend so much time in our jobs, and there is always a story there. It’s richer than anything you can communicate via a series of bullets about your skills. I want to describe the circumstances of the work. Give some key milestones of my employment. Describe the projects and outcomes of my work. Creative types will augment resumes with portfolios. What about the rest of us?

It occurred to me that infographics are good for my purposes. They get across key information in a narrative using a visually interesting style. But they don’t require a significant investment of time and focus for the reader. So I created my own infographic to describe the context and work of my time at Spigit:

I tried using one of the infographic-generation sites, but wasn’t satisfied with the results. The default templates didn’t match the story I wanted to tell, I wanted to do more with the interplay of text and graphics, and the PNG image upload was buggy. Instead, I used two free apps to make it:

Google Docs – drawing app
GIMP image program (installed)

I exported the Google Drawing to PDF. To turn the PDF into a high resolution PNG file, I followed the advice on this StackExchange post.

The final question is where to put the infographic. It doesn’t exactly fit a standard letter (U.S.) or A4 size, so you can’t append it to your resume. So I’ve uploaded it to Slideshare and Scribd, added it to my LinkedIn profile, and it graces the About Me page of this blog. Would be kind of daring to send it to a prospective employer, eh?

If you’re interested in creating one of these, feel free to contact me. I can offer you what I learned in making it. And in case you’re wondering, Spigit’s revenues are publicly available via SEC filings by its lead investor PICO Holdings.

I’m @bhc3 on Twitter.

Filed under mba Tagged with careers, infographic, mindjet, product management, resume, spigit

Latent needs are overplayed as an innovation dynamic

October 22, 2013 by Hutch Carpenter 12 Comments

Reading this thought piece from the Silicon Valley Product Group, The End of Requirements, I saw this point about latent needs:

Unrealized needs (also called “latent needs”) are those solutions where customers may not even be aware they even have the need until after they see and experience the solution. Examples include digital video recorders, tablets, always-on-voice, self-driving cars, etc.

In other words, customers often don’t know what they want. This is essentially another version of the Henry Ford quote, “If I asked people what they wanted, they’d have said faster horses.”

I want to differ with the Silicon Valley Product Group here. People do know their needs, it’s incumbent on companies to understand them. Then it’s appropriate to try out ideas that can better satisfy those jobs. This diagram illustrates the two separate dynamics:

In their post, they use self-driving cars as an example of “latent needs”. Two issues with that. First, self-driving cars are not yet in the market, so it’s not possible to say that was a latent need, as described by the Silicon Valley Product Group. The second issue is that self-driving cars will actually address known jobs-to-be-done. I wrote a whole post on that, Exactly what jobs will self-driving cars satisfy? In that post, I outline several jobs-to-be-done and some key outcomes desired:

Job-to-be-done	Outcomes
I want to get from point A to point B	Minimize commute time \| Minimize accident risk \| Minimize commute risk \| Increase driving enjoyment
I want to get work done	Increase digital work completed \| Increase availability for conference calls \| Minimize distractions
I want to improve the environment	Minimize emissions \| Minimize fossil fuel consumption
I want to enjoy my personal interests	Increase spent on activity \| Minimize distractions

The point here is that these are not latent needs. Some are needs that people do not think about now in the context of commuting in a vehicle. But they are not latent needs.

I do agree there are some needs that can be hard to discover, or which become more important as societal norms and expectations change. Sure, there are some needs that are not obvious and may indeed become more visible in the face of a potential solution. But these are exceptions, not the norm.

Making product and innovation decisions based on the thought that, “Well, people don’t really know what they want” is a recipe for a lot of wasted effort. It’s not a sustainable basis for growth.

Agree? Or think I’m oversimplifying things?

I’m @bhc3 on Twitter.

Filed under mba Tagged with customer insights, innovation, jobs to be done, jtbd, latent needs

Generate opportunity maps with customer jobs-to-be-done

October 17, 2013 by Hutch Carpenter 2 Comments

In seeking to better understand customer jobs-to-be-done, I found myself a bit underarmed. Meaning, I didn’t really have a way to do this. The value of jobs-to-be-done (JTBD) thinking has only emerged recently. It’s still nascent, and there aren’t ready guideposts to follow. However, Tony Ulwick has been at it over two decades. Indeed, his outcome-driven innovation remains a powerful methodology with the structure needed to effectively identify opportunities. It is the JTBD standard.

But in my work, I wasn’t ready to engage external consultants. My project was more low level, relating to a significant enhancement to an enterprise software platform. My needs – and budget – didn’t rise to the level of a full-fledged consulting engagement. Also, I wanted to be the one talking with customers.

So I did what anyone interested in innovation would do. I hacked my own approach. I wanted a way to elicit jobs-to-be-done that had the following aspects:

Accessible anytime I wanted it
Low cost (free!)
Allowed me to rank different jobs-to-be-done
Created a way of seeing where the opportunities are
Deepened my understanding of, and connection with, customers

The presentation below outlines a method to generate opportunity maps with customer jobs-to-be-done:

——-

As you’ll see in the presentation, I consider this an initial blueprint. One that can, and should, be hacked to optimize it. But as the approach exists now, it will provide significant value. And for those who haven’t engaged customers at this level of dialogue, you’ll be amazed at what you learn.

Give it a try and let me know what value you get in talking JTBD with your customers.

I’m @bhc3 on Twitter.

Filed under mba Tagged with innovation, job-to-be-done, jobs to be done, jtbd, strategyn

Exactly what jobs will self-driving cars satisfy?

September 30, 2013 by Hutch Carpenter 18 Comments

On Twitter, I made this observation about the future of self-driving cars:

Our kids will have a very different "driving" experience. Self-driving cars allow them to work during transit, and improve safety. #jetsons

— Hutch Carpenter 🌻 (@bhc3) September 22, 2013

A moment later, Megan Panatier made this skeptical counterpoint:

Whenever I hear people talking about self driving cars, I think, yeah those are called trains.

— Megan Panatier (@MeganPanatier) September 22, 2013

This is a great example where it pays to consider the jobs-to-be-done. Self-driving is in the realm of experimentation right now. There’s no hindsight of how obviously this was going to be a success. Self-driving vehicles could end up being the next Segway. An interesting technology that never catches on.

Image via Engadget

How can we begin to know self-driving cars’ fate? Do some outside-in market analysis. Understand what jobs-to-be-done relate to the act of commuting. Know those, and you can determine what opportunities exist for self-driving cars.

To that end, here are four relevant jobs-to-be-done that I see:

I want to get from point A to point B
I want to get work done
I want to improve the environment
I want to enjoy my personal interests

Where can self-driving help? Know that, and you can see how it will fare in the future. In the analysis that follows, self-driving is compared to two common alternatives: regular, manually driven cars; and public transit like buses and trains. Concepts from the Strategyn jobs-to-be-done innovation approach are used to assess the alternatives: outcomes and satisfaction with those outcomes. While a typical job has 50 – 150 outcomes, we’ll focus on a few summary level outcomes here.

Job #1: Point A to Point B

This is the core job of driving. Getting from one place to another. What’s key here is understanding the important outcomes that are desired for this job. The table below shows outcomes for this job, and how well satisfied they are for different transit alternatives.

Outcomes	Regular car	Bus & train	Self-driving
Minimize commute time
Minimize accident risk
Minimize commute stress
Increase driving enjoyment

Reviewing the desired outcomes, where might self-driving vehicles provide an advantage? It’s dependent on how the different alternatives are considered. For instance, self-driving vehicles will not provide better commute times than manually-driven cars. But they are better than what buses and trains provide. Buses and trains are bound by set routes and schedules. These inject delays in commute times. Cars generally have an advantage here because of their direct door-to-door operation.

But self-driving vehicles do provide improvements over regular cars on two other outcomes: accident risk and commute stress. A great opportunity in ‘accident reduction’ applies to driving under the influence of alcohol. Self-driving cars will get you home safely. In this sense, they are more akin to what Megan Panatier tweeted. They’re like trains.

Taking those three outcomes together, it becomes clearer that self-driving vehicles will provide greater satisfaction on the Point A to Point B job-to-be-done.

There is one outcome where self-driving cars are a step backwards: driving enjoyment. Think about those commercials with high performance vehicles speedily taking curves on beautiful rural roads. The high performance manually driven car market will still be intact even in a world of self-driving vehicles. People will want that visceral pleasure.

Job #2: Get work done

A recent survey sponsored by Jive Software highlighted that people are working outside office hours more and more. While the causes of this vary, the result is that this has become an important job-to-be-done for many. Let’s look at the key outcomes for this job.

Outcomes	Regular car	Bus & train	Self-driving
Increase digital work completed
Increase availability for conference calls
Minimize distractions

Self-driving vehicles really shine in this job-to-be-done. They essentially become traveling offices. Fewer distractions and the ability to focus on the work tasks at hand.

The other advantage is better availability for conference calls. Ever tried to be on a work call while driving? Your focus is diverted by driving issues. And you really don’t want to be one of those people who loudly talks on the phone while commuting on a bus or train. When a conference call includes a shared screen, you can participate on that via the self-driving vehicle vs. driving a car.

Getting work done is one of those jobs that you might not associate with commuting. But self-driving opens up the ability to better satisfy this longstanding job.

Job #3: Improve the environment

Improving the environment continues to be an important job-to-be-done for a majority of Americans, and the world. And driving is a critical aspect of environmental impact. Two outcomes are assessed for this job below.

Outcomes	Regular car	Bus & train	Self-driving
Reduce emissions
Reduce fossil fuel consumption

When self-driving vehicles are considered as replacements for trains and buses, it’s possible that environmental benefits may be conflated between the two alternatives. Public transit is often touted for its environmental benefits.

But self-driving cars are not public transit. They will still have the same environmental impact of regular cars. Now, as automakers continue to improve the environmental impact of vehicles (electric vehicles, hybrids), then self-driving cars will follow the same improvement curve as regular cars.

However, self-driving vehicles provide no improvement on satisfaction for the key outcomes of the environmental improvement job. Indeed, to the extent they replace public transit (bus, train), they could contribute to increased environmental issues.

Job #4: Enjoy personal interests

Enjoying personal interests is a job that we do everywhere. Read in bed. Crochet during a television program. Engage in physical activity. Video gaming. There are numerous individual jobs-to-be-done here, but we’ll lump them into a summary job for this analysis. Below are two outcomes for this job-to-be-done.

Outcomes	Regular car	Bus & train	Self-driving
Increase time spent on activity
Minimize distractions

Similar to the ‘get work done’ job, this job is well served by self-driving cars. Regular cars really prevent the ability to enjoy a range of personal interests, due to the majority of time spent on…actually driving.

The individually controlled environment of a self-driving car also facilitates more engagement in personal interests. No competing phone calls, loud conversations, crowded space.

Self-driving vehicles will be fantastic for this job-to-be-done.

Conclusions

Based on analyzing the jobs-to-be-done, two conclusions can be drawn about self-driving vehicles.

Target market: urban areas. The jobs and outcomes outlined herein point to a better fit of self-driving vehicles to urban areas and the surrounding suburbs. People have longer, more stressful commutes than in rural and lower population areas. They also tend to have professional employment where digital work and conference calls are more the norm.

Urban areas do not lend themselves to driving enjoyment. Hard to take those curves when there are red lights, sharp corners and lots of traffic around you. So the ‘increase driving enjoyment’ outcome – a weakness of self-driving – is less relevant in these geographies.

Future design. The current look of a self-driving vehicle is essentially that of a regular car. And why not? The technology is being tested and iterated. No need to adjust a car while the technology is on that stage.

Eventually, self-driving technology will be perfected and be ready for broader adoption. Then the jobs and outcomes outlined herein become more relevant. What we currently know for car interiors and shapes will most certainly change. The basis of design changes from optimizing the driving experience (the outcomes) to optimizing for other jobs-to-be-done. One can imagine basic manual override driving capability for vehicles as a back-up in case the self-driving technology fails.

But the focus of design changes. Vehicles will be optimized for existing jobs-to-be-done that can now be newly satisfied via the self-driving technology. And new internal accessories will be developed to take advantage of this expansion of the market through increased jobs-to-be-done. Like a little exercise during the commute? How about a modified stationary bike inside your car?

Self-driving vehicles will be a source of significant new market opportunities.

I’m @bhc3 on Twitter.

Filed under mba Tagged with jobs to be done, jtbd, outcome-driven innovation, self-driving, self-driving cars, vehicles

← Older posts

Newer posts →

Product themes

Past + possible features = proof

How we’ll work with the client

Look for 5 blade razors.

Ignore the best customers.

Understand why the product is hired.

Flip the coin.

Firm request from a priority customer?

Priority customer

Firm request

Multiple similar requests?

Meaningfully enhances outcomes?

Committed to maintaining feature?

Decide on the request

Decline the request

Address the request

Start with the job flow

Job task

Collect jobs tasks for each activity

Job canvas

Top tasks by importance and dissatisfaction

Number of customer interviews

Create affinity groups

Bring together group of people do the affinity grouping

Put all the job tasks on a wall

Group similar items

Label the groups

Calculate the importance and dissatisfaction score for each group

Prioritize roadmap

What works? Survey says…

Factors that make customer involvement successful

Chief Customer Development Officer

Invention creates. Innovation changes.

1. Because Apple, Microsoft, Google did it!

Context

Product-first thinking

Analysis

2. The “what you can do for us” attitude

Context

Product-first thinking

Analysis

3. Dazzled by the invention

Context

Product-first thinking

Analysis

4. Same template, different market

Context

Product-first thinking

Analysis

5. Blaze a new trail

Context

Product-first thinking

Analysis

6. What Steve Jobs said

Context

Product-first thinking

Analysis

7. My business model demands your attention

Context

Product-first thinking

Analysis

8. Solution in search of a problem

Context

Product-first thinking

Analysis

9. We’ll get to those customers at some point

Context

Product-first thinking

Analysis

10. Dazzled by the innovator and the hot trends

Context

Product-first thinking

Analysis

Wrap-up

Are you asking ‘why’ enough?

HP large format graphic plotter

Spigit innovation management platform

Job #1: Point A to Point B

Job #2: Get work done

Job #3: Improve the environment