When customers want a product roadmap, do this instead

February 10, 2014 by 8 Comments

Product roadmaps suck.Roadmap

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:

  1. Where will your development resources be focused over the 12-36 months?
  2. Does your view of what’s needed for successful outcomes matches mine?
  3. 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

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:

Theme + features

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:

Customer insight in product design

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.

Advertisement

Filed under mba Tagged with , , , , ,

Decision flow for customer feature requests

January 28, 2014 by 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:

B2B 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:

  1. Identify all similar requests that have been made by different customers
  2. 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 , , , , , ,

The Folly of Inside-Out Product Thinking

December 12, 2013 by 2 Comments

Inside out jacket

Inside out just doesn’t fit right

Ever run into this deductive reasoning?

  1. Customers like our existing products and our company
  2. We are building a new product that reflects the priorities of a company executive
  3. 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:

I’m @bhc3 on Twitter.

Filed under mba Tagged with , , , , , , ,

10 examples of fabulously flawed product-first thinking

November 5, 2013 by 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

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

Color website is deadContext

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 , , , , , , , , ,

Tell your work story with an infographic

October 28, 2013 by 8 Comments

Resume screen shot - reflectionI 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:

VP Product Spigit infographic

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 , , , , ,

A Method for Applying Jobs-to-Be-Done to Product and Service Design

January 15, 2013 by 15 Comments

Say you’re designing something new for a product or service. Of course, you have your own ideas for what to do. But, how informed are you really about what is needed?

This is a question I faced in thinking about game mechanics used in a social platform. A common product approach is to work up some game mechanics ideas, get them designed and deployed. The source for ideas? My own fertile mind. Inbound suggestions (“in World of Warcraft, you can…”). Competitors. What companies in other markets are doing.

But that wasn’t sufficient. Game mechanics are an evolving, somewhat complex field.  I wanted to understand at a more fundamental level: why game mechanics? So I decided to learn more from our customers. What needs would game mechanics address? Initial question: what’s the best way to go about this?

Jobs-to-Be-Done: Only for game-changing innovation?

The jobs-to-be-done framework struck me as the right approach here. What are customers trying to get done? As legendary professor Theodore Levitt said:

People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.

Similarly, I didn’t believe customers wanted to buy “game mechanics”. They want to buy results, which game mechanics can help deliver. Using the jobs-to-be-done framework, what jobs were game mechanics being hired for?

Yet, in reading the advice on jobs-to-be-done, one gets the impression that eliciting jobs-to-be-done can only be done effectively via intensive in-person interviews. Well, I didn’t have the capacity to fly around for one-day deep-dive sessions to understand the jobs-to-be-done related to game mechanics.

Customer Insightini

And this gets at something related to jobs-to-be-done as it stands today. It’s very much positioned for high-impact, game-changing innovation. Which is awesome, by the way. Firms like Strategyn and ReWired Group are setting the tone here. When the payoff for intensive, expensive efforts like in-person interviews is high-value innovation, you do them.

But my needs were at a lower level than that. In the Customer Insightini™ to the right, I segment the types of initiatives where customer insight can be useful. The bottom is the minor stuff (“it should support colors red, green, blue…”). The top is the game changing endeavors (e.g. surgery stents). My game mechanics inquiry? Right there in the middle. Introduction of something new in the same market.

Since I couldn’t find a good framework to elicit customers’ jobs-to-be-done, I hacked together my own methodology. It’s described below.

  1. Job-to-be-done structure (link)
  2. Focus the effort (link)
  3. Rate satisfaction with fulfillment of each job (link)
  4. Rank order importance of jobs to create an Opportunity Map (link)
  5. Use a website to manage the jobs-to-be-done (link)
  6. Conversations are as valuable as the jobs themselves (link)
  7. Step-by-step plan (link)

Job-to-be-done structure

I needed a common language for the various jobs-to-be-done. Specifically, I needed a reliable format that provided the right information. I came up with the following:

Context: “When I am…”

Job: “I want to…”

Success metric: “Increased…”

Context is important, because I want to understand the background for the job to be done. When did it happen? What was the larger goal? The job itself is the core information to be collected. The success metric told me what the customer valued in an outcome, and provided a basis for measuring whether the idea implemented to fulfill the job was actually doing so.

Focus the effort

Something I’ve learned in the realm of innovation management: focused initiatives outperform post-whatever-you-want initiatives. In other words, participants should be asked for insight on a specific topic. Otherwise the exercise risks spinning off in many directions you’re not ready to pursue.

In the game mechanics effort, I started with a definition of gamification itself. This set the tone for the discussion. I believed there were several areas that could benefit, so I focused the discussion around collaboration, engagement and three other areas. This framed the discussion without corralling customers too tightly in what they wanted to express. It also gave a nice rhythm, as we worked through each of the five areas.

Unsurprisingly in the discussions with customers, they had ideas for applying game mechanics to a job-to-be-done. Since the discussion was focused on their needs and wants, I would take these ideas and add them to a separate idea community.

Rate satisfaction with fulfillment of each job

This step was critical. It wasn’t enough to have the various jobs-to-be-done. Understanding the level of satisfaction with each one is the metric which shows where good opportunities lie.  I asked customers to bucket each job-to-be-done as:

  • Satisfaction with current outcomes = HIGH
  • Satisfaction with current outcomes = MODERATE
  • Satisfaction with current outcomes = LOW

Now, there was a natural bias for customers to provide jobs where their satisfaction was lower. They wanted to talk about things that need to be improved. But I wanted to ensure a broader look at the landscape of jobs. So in the course of the discussion, there were three sources of jobs-to-be-done that came outside of these  low-satisfaction ones:

  1. Seeded obvious jobs: I seeded the site with some of the more obvious jobs, to provide examples.
  2. Jobs provided by previous customers: As I learned new jobs from a previous discussion, I’d add them to the new discussion. This was good to see how customers felt about what others were trying to get done.
  3. Jobs elicited in discussions: After getting one job from a  customer, we’d discuss it. In that discussion, you’d hear another job-to-be-done. While that one may not be low satisfaction, it was important to capture it for a fuller understanding.

As you can imagine, there were varying views on level of satisfaction for the same job across customers. Is the software performing differently for each? No. But each customer was communicating the level of outcome they deemed satisfactory.

Rank order importance of jobs to create an Opportunity Map

After the jobs were sorted into the LOW, MODERATE, HIGH satisfaction buckets, I asked the customer to rank them in relative importance, highest to lowest. This was their chance to tell me just what they valued most. Even if their satisfaction was moderate with a job’s outcome, it was valuable to know what they deem most important. Useful for fuller understanding of why customers buy. Because you want to avoid being one of these companies:

The vast majority of companies have no clue what their customers value in the products and services they buy.

Here’s what you get after you’ve done this: an Opportunity Map as determined by the customer’s expressed needs.

JTBD Opportunity Map

After talking with each customer, you’ll be able to generate an Opportunity Map. By aggregating the responses by customers, you have a broader Opportunity Map    that begins to reflect something of the market.

Use a website to manage the jobs-to-be-done

The preceding elements of eliciting jobs-to-be-done are the method. The method needs a place to execute it. For my gamification project, I used the free post-it note site Listhings. With that site, I can add unlimited canvases (for different customers) and individual notes (for the jobs). You can color code the different sub-topics within the question you are asking.

Examples of Listhings culled from an actual customer discussion:

Listhings example

Conversations are as valuable as the jobs themselves

In the process of collecting the jobs-to-be-done, I found the discussions around each job-to-be-done to be incredibly valuable. And this is an important point: customers want to talk to you about what they’re trying to get done! The discussions were intelligent and gave me insight into their world. An insight I cannot get from data about usage or the user stories I write in a vacuum.

This experience is what makes me cringe when I read others throwing around the old Henry Ford chestnut: “If I had asked people what they wanted, they’d have said faster horses.” It assigns customers to the Dumb Bucket.

Interesting experience in doing these with 8 different customers. I would schedule a one-hour session with our admin leads at each. Inevitably, we’d run out of time in that first session. Every single customer was up for a second session. One customer even wanted a third and fourth session, bringing actual end users into it for their perspective.

Perhaps this can be a good path for a design thinking approach, as it really boosts your empathy for what customers are trying to get done as you discover their jobs-to-be-done.

Step-by-step plan

OK, that was a lot of information about individual parts of this jobs-to-be-done methodology. Let’s put it together into a plan:

  1. Establish a topic you want to explore more deeply with customers.
  2. If the topic is somewhat broad, break it down into sub-themes.
  3. Sign up for a site where you can collect jobs. Criteria for such a site:
    • Each job is visible in full on screen
    • Ability to segment the jobs by sub-themes
    • Ability to categorize jobs by level of satisfaction
  4. Seed the site with some obvious jobs that your product/service provides.
  5. Select customers to engage.
  6. Use a web/screen sharing tool to run the discussion (e.h. WebEx, GoToMeeting, Skype, Google Plus).
  7. Plan for an hour, expect to need a second one.
  8. As you talk with the customer, post the jobs in real time so she sees them on screen.
  9. Run through the satisfaction bucketing (LOW, MODERATE, HIGH)
  10. Rank order the jobs within each satisfaction bucket
  11. Collate and aggregate the responses after you have finished the customer discussion. I used Excel for this.
  12. Identify the jobs that were most important and received LOW or MODERATE satisfaction across your customers.
  13. Plumb your notes from the discussions for additional insight that will be useful

The other thing you’ll gain from this are customers who have a demonstrated interest in the phases that follow in the design and development process: ideas, prototypes, early purchasers.

I’m @bhc3 on Twitter, and I’m a Senior Consultant with HYPE Innovation.

Filed under mba Tagged with , , , ,

Jobs-to-be-done’s place in a customer-centric organization

May 16, 2012 by 5 Comments

On Twitter, I asked this question:

I asked it, as I had a conversation in recent days with a fellow from a large corporate. Customer-centricity was recently adopted as an internal mantra, but the manifestation of that was…wait for it…sentiment analysis.

It’s a start, right? But is it really a difference-maker?

I’ve written recently about jobs-to-be-done. As in, what customers hire your product to do. Those jobs have a tendency to (i) be hidden from you; and (ii) change over time. Knowing, and acting on, jobs-to-be-done (JTBD acronymized) is probably one of the most customer-centric things a company can do. You’re getting deep into what someone is buying your product for.

While I don’t work for a large corporate, I am integrating jobs-to-be-done in some work on next generation gamification elements for the Spigit platform. Why? Because there are many different types of game mechanics that can be applied to a platform. But why would you add any of them? To better deliver on what your customers hire you to do. To accomplish this, I’m using the Listhings site – online post-it notes – to collect and socialize these. I follow my own format for JTBD: context, job, success metric. An actual (blurred-out) example is below:

You know what? Customers love talking about their jobs-to-be-done. Seriously.  I usually schedule an inital hour to talk about them, and every single company has wanted to continue to the conversation for another hour. The conversations are not just good customer relations, which they are. They are leading to areas where the Spigit platform can apply game mechanics to improve their outcomes.

But apparently, this approach is sort of radical. As only 7% of firms are deemed to be customer-centric.

Where would JTBD fit?

Which got me thinking. What exactly are companies doing today, at least in the product and service development arena? Where would customer jobs-to-be-done fit with existing approaches? The graphic below is my take on what’s happening out there:

The center blue area represents the work of ideating, designing and producing products and services. The top grey boxes floating around up there? Those are the current factors influencing the product/service development process.

Market Analysis: Classic input for product development here. What are the trends? What are competitors doing? What’s going on in adjacent markets? You’re got to do this. It’s a source of ideas, and evidence of what customers are gravitating toward.

Executive Fiat: Does this really happen??? Heh, just joking of course. This will be a reality forever, and it’s actually appropriate in mild doses.  The thing to watch is the bull-in-the-china-shop approach, where that product is gonna get done, I’m not listening to anyone! Perhaps too many executives subscribe to the Steve Jobs-attributed notion that customers don’t know what they want (“So I’m going to give it to them!”).

Usage Vectors: Once you have product out there, you learn what people are using, what they value in the existing product features. And you continue to develop along those vectors. It’d be irresponsible to do otherwise. Just watch getting stuck on those vectors and missing the market shifts.

Customer Service Tickets: As people use your product, they’re going to file requests and report issues. These items are some clues to what people are trying to get done. They suffer from being narrow, focused on a specific interaction point and grounded in what they know of the current product. But you can divine some of what people want to get done from these.

Customer Surveys: Surveys get you closer to customers. Polling people’s preferences for difference attributes and behaviors. Good input as you consider a product or venture. Problem with surveys is that the questions are set ahead of time. Whoever puts them together has to decide what the key factors are. But that leaves a huge hole in understanding what customers themselves value.

Focus Groups: A favorite activity of large companies is to get some random people in a room for a couple hours and ask them about some concept being tested. In that these sessions have actual people talking, they are nominally useful. But common critiques of these are that

  • Participants tell researchers what they want to hear
  • The format is unnatural – forced face-to-face interactions with strangers for two hours in a closed room
  • Alpha personalities sway things
  • What’s discussed are already-decided concepts, not insight on what customers are looking to get done

As was stated in this 2003 Slate article, “The primary function of focus groups is often to validate the sellers’ own beliefs about their product.”

Jobs-to-be-done fills a gap

In all of the popular bases for developing products and services, one can see a gap. Most are a triangulation to understanding what customers want. Now some are quite useful in a customer-centric sense: usage vectors, customer service tickets, surveys. But they’re also piecemeal.

They represent the hope that you’ve got a bead on customer needs and wants.

Why the reluctance to actually talk directly with customers? Seems plain talk in a (not overly) structured way will give you a better sense of where opportunities lie. Aside from the product/service tools listed above, there are the social media engagement practices of today (react to tweets, have a Facebook page, sentiment analysis). All have their place, but they fall short.

Want to be customer-centric? Try talking to your customers.

I’m @bhc3 on Twitter.

Filed under mba Tagged with , , ,

My Ten Favorite Tweets – Week Ending 042310

April 24, 2010 by Leave a comment

From the home office in some Redwood City bar, where I’m using my pick-up line on all the single ladies, “Did you happen to find my Congressional Medal of Honor around here? Or my iPhone 4G?”

#1: RT @TechCrunch Foursquare Becomes More Business-Friendly http://tcrn.ch/b45AJY > Biz owners can claim their businesses

#2: RT @jowyang Heard that foursquare us charging brands $50,000 for a custom branded badge. Good deal or bad? Think it through.

#3: RT @courtenaybird GOOD READ: It’s Time For An Open Database Of Places http://ow.ly/1A4HL (via @erickschonfeld)

#4: RT @briansolis The State and Future of Twitter 2010: Part Two http://bit.ly/aAV0r9

#5: “Sucks Less” Features http://bit.ly/an6s50 > funny product management perspective from my b-school classmate @trochte

#6: RT @amcafee New blog post up. “Drop the Pilot” advocates AGAINST small-scale #E20 pilot projects: http://bit.ly/aKD3WF

#7: This @gapingvoid cartoon well-describes the creative process, incl writing. http://bit.ly/9LlVIN Sometimes you got it, sometimes you don’t.

#8: Had to check to make sure this wasn’t dated April 1. It’s for real: “Vacationing a human right, EU chief says” http://bit.ly/bMYAH0

#9: I hear stories about Americans’ deep discontent with government, and I’m just not one of them. We’re working our way out of a deep well.

#10: Hilarious site that any parent of young kids can appreciate: www.shitmykidsruined.com (h/t @rochelle)

Filed under geek Tagged with , , , , , , , ,

My Ten Favorite Tweets – Week Ending 010810

January 9, 2010 by 1 Comment

From the home office in Sacramento, where Governor Schwarzenegger laid out an initial budget that will take 11 months to resolve and pass…go ahead and get your California jokes ready now…

#1: If this topic interests you – Designing for Innovation through Competitive Collaboration – I ask for your #e2conf vote http://bit.ly/8xuQuC

#2: The Wisdom of Crowds Like Me http://bit.ly/4WM1Bi #crowdsourcing

#3: How Do Product Managers Reject Bad Ideas? http://bit.ly/7j6Ax0 by @chriscummings01 #innovation

#4: Jessica Hagy: The Visual Grammar of Ideas :: Articles :: The 99 Percent #innovation http://post.ly/HcJL

#5: Should you be thinking about Enterprise 2.0 in 2010? http://cli.gs/th9me by @dahowlett > A rare, rare bit of optimism there #e20

#6: MITRE’s intranet, including its Spigit deployment, is named to Jakob Nielsen’s Top 10 Intranets for 2010: http://bit.ly/5jrgJY #e20

#7: RT @dhinchcliffe The K-factor Lesson: How Social Ecosystems Grow (Or Not) http://bit.ly/8aEQEQ

#8: RT @paujoral Great quote by @wimrampen: “the name of the (social networking) game is how to participate in knowledge flows”

#9: Just had to use the “Let Me Google That for You” site for a colleague: http://lmgtfy.com/

#10: This is both funny and so true: Effect of Bay Area earthquakes on Twitter traffic http://twitpic.com/x3c10 (h/t @louisgray)

Filed under geek Tagged with , , , , , , , , , , , , ,

My Ten Favorite Tweets – Week Ending 052909

May 30, 2009 by 1 Comment

From the home office in Pyongyang, North Korea…

#1: Twitter may add some FriendFeed features to the service, is what @scobleizer heard today at #140tc http://bit.ly/d87Av

#2: Business Week includes the Cisco fatty story in its article about managing corporate reputations online: http://bit.ly/3ZCG9

#3: @justinmwhitaker I take a broader view on innovation. The perception is that it’s all Clay Christensen disruptive. Most will be incremental.

#4: You know what I like about working at Spigit? Plenty of competition out there. Fun to see them laying the smack down on us. Love it.

#5: Four of the most damaging words to corporate innovation an employee can say: “Aww, forget about it” #innovation

#6: Great post on critical distinctions in #e20 use cases, and ‘collaboration’ vs. ‘participation’ by @johnt http://bit.ly/12umLp

#7:  @dhinchcliffe Very keen to hear enterprise perspectives on Google Wave. Will it compete w/ SocialText, Socialcast, CubeTree, Yammer?

#8: When does a company need a dedicated product mgt function? $1.5-$3.0 mm in revenue and/or 20-25 employees: http://bit.ly/C2CTr

#9: Dara Torres sets a new record in 50 meter butterfly http://bit.ly/lsRER And sadly, I find myself wondering how a 42 y.o. is setting records.

#10: Just looked at my E*Trade account for the first time in months. Less bad than I thought.

Filed under geek Tagged with , , , , , , , , , , , , , , , , ,