Category: Product Strategy

Find the real “jobs to be done” by analyzing what prospects do

Photo by Todd Quackenbush on Unsplash

Why do people buy a new solution? They are often dissatisfied with an existing way of solving their problem, need to solve a new problem, or see something brand new that looks cool. Clayton Christensen calls this search to find a substitute product “looking for a job to be done.”

People don’t simply buy products or services; they pull them into their lives to make progress. We call this progress the “job” they are trying to get done, and understanding this opens a world of innovation possibilities. (Christensen Institute)

The Jobs To Be Done framework is a way to enable the buyer to explain the purpose that caused them to buy new software. It also lets the selling company better align the underlying work required to match the capabilities that the company offers through its software to the real work the buyer needs to be done. We call it a “Job to Be Done” because like a person you would hire to do this work, you have specific requirements and a way to fulfill them to feel satisfied that this software is a good fit to solve this problem for your organization.

The “job” in the case of software often spans the needs of multiple people:

  1. the person who immediately needs the job to be done (and who would otherwise be using some other substitute to finish the work)
  2. the other people in the organization who work closely with that person and supply inputs and receive outputs from that person
  3. the economic buyer who is deciding whether or not to purchase

On the surface, this software buying process seems relatively straightforward. It’s often messy because it’s informed by people indicating what they want to do, not always duplicating what they’ve done in the past. The “software” is really a stand-in for the match between the buyer’s idea of the capability needed and the seller’s assessment of how to match the software to that result.

The team at Intercom created this buyer journey diagram to track the experience of a prospect from initial awareness through consideration to buying and beyond. It does an excellent job of summarizing the timeline for that journey in terms of the stages the customer transits.

Intercom on “Jobs to be Done”, p.18

What’s missing from this diagram? The process the customer is using today to get the work done, or their description of the process they propose to get the work done. The critical path to deciding what will be good enough to “hire” your product for the Job to be Done is not always described by the job to be done.

Challenges with the Jobs to Be Done Framework

Frameworks are tools and are not complete playbooks for every situation. We know this to be true because the results are not consistent across the board among teams that are trying to innovate. For example, “84% of global executives reported that innovation was extremely important to their growth strategies, but a staggering 94% were dissatisfied with their organizations’ innovation performance.” (“Know Your Customers’ ‘Jobs to Be Done’”, Harvard Business Review, Sept 2016)

What’s the real driver of innovation? Some combination of a good frame, willing and effective facilitators, and people in the organization who want to change. John Cutler, a product evangelist at Amplitude, writes: “You want a framework that describes what people should do when they should do it, and how they should do it.” But that doesn’t usually work, as Cutler describes in this article.

TBM 39B/52: Crawl, Walk, Run, and the Fragility of Frameworks(opens in a new tab)

What’s really going on here?

Change management (the selection of a new product) requires people, process, and technology to be coordinated to select the right job to be done and the product to do it.

People overweight the benefits of the solution they have. Innovators overweight the value of their solution. Multiplying these factors gives you a need to produce a really big change to nullify these effects. Gourville’s “Eager Buyers, Stony Sellers” explains it this way:

Gourville’s “Stony Buyers, Eager Sellers” from Intercom’s Jobs to Be Done

The process that you follow works when you focus both on breaking through the resistance of the existing solution and identifying the results you need to call the job done. These results are not usually bound by technology, but by the prospect’s belief that you can solve the problem better than they are doing today. To build this trust, you need a safe place for people to explore while getting fast feedback.

This is hard because it’s a leap of faith. For people who want to get their hands dirty and do the work themselves, it means giving them enough access and skill in the platform to prototype a solution and make it work. For people who are not going to do the work themselves, they need to gain confidence that the proof of concept you are building during consideration.

Buyers need to know why the new thing is better. They need to know they can solve the problem they set out to resolve. And they need to stop worrying about the things that could go wrong.

How to find the real Jobs to be Done

Given the constraints that make it hard to follow a framework perfectly, what should you do to enable your prospect (and your sales team)? The prospect needs the space to explain how they want the problem to be solved. You need to know how to translate these requirements into tangible tasks that you get done in your software.

To find the real Jobs to be Done, you need to remove barriers and objections from the prospect.

Here are a few suggestions:

  1. Prototype a proof of concept similar to the desired solution: if possible, use something that already exists as a model
  2. Build in a low-stress environment: don’t write changes to any production system
  3. Prove that you can deliver the result as a proof of concept: produce the result you want to see in production, and do it in a sandbox

When you demonstrate a solution to the buyer that uses their data, looks like a solution they would use, and delivers a favorable result? That’s the Job they want Done.

What’s the takeaway? Jobs to Be Done is a helpful framework to think about delivering results for the prospect while making software selection a buyer-centric process. The framework alone won’t do the trick: you need to align the prospect’s needs with the solution to overcome the 9x effect.

0

A modest proposal for Slack Overload

Photo by Luis Villasmil on Unsplash

How do you keep up with these Slack communities that are out there?

For many of us, opening Slack creates an overwhelming feeling of “FOMO” (Fear of Missing Out). When all of the channels light up with notifications, you collapse the channel view, mute the channel, or just close Slack altogether. But wait! You’re missing out!

You could read everything. That’s not very effective, especially if you belong to multiple communities that post a lot.

What are some potential solutions to keep in touch with a community and avoid information overload? Closing Slack is one option and leaves you out of the loop. Setting up notifications to message you on certain topics is a blunt force instrument. Customizing the settings on each Slack community you join is too much work.

Why is Slack difficult to use? Here are a few reasons.

  • It all looks like a text “waterfall”. When you log in to a Slack community with lots of members, you often see many messages and need to choose whether to skip reading or “backscroll” and read them all.
  • What are people talking about? Because there’s no topic clustering, it’s hard to determine the larger themes in a group of messages. 
  • Channels have no inherent context. There may be a channel topic but people tend to talk about anything. The topic doesn’t limit the messaging or provide suggested guardrails.
  • Search is, at best, minimal. Good luck searching that message you remembered from a few days ago. If you limit your search to a particular channel, you will also limit your ability to search for it elsewhere.
  • All Slack instances look the same. The good news is that if you’ve used Slack before, you know how to use Slack. The bad news is that you might not remember which instance you’re using. The only clear differentiator by default is the logo, the url, and the channel names. This can get even more confusing if you know people in multiple slack communities and communicate with them in more than one place.

The cognitive overflow of using multiple channels and messaging services is real. So what could we do to make communities like Slack easier to use?

Solutions to this problem would increase the signal for interesting messages but boosting them somehow in your feed. It would also be great if Slack made it easier to find relevant information and related topics to your posts.

Slack has the API to make this happen. What could we address with a bot that aggregated information to help message overload?

Here are a few suggestions to make community involvement more effective in a noisy Slack community. These solutions could be addressed with an aggregator bot in Slack – I’m not as familiar with technology in other community services like WhatsApp or Microsoft Teams, but don’t think they are quite as open as Slack’s API.

I’d like to solve these problems that occur in busy communities:

  • What were the active conversations I missed? A feature might review conversations and Identify the “most active conversations” in a time period from the channels where you are a member, linking you the top 3 in the last 24 hours or a larger time frame if the community is quiet.
  • What did these conversations reference? Identifying the relevant topics from active conversations would be very useful. Also, it would neat to have a topic map of all of the public channel conversations in a community. Think of what Roam Research is doing to identify entities in individual documents and you’ll have an idea of what you could do to auto-tag conversations or channels with topics.
  • Is the conversation changing over time, and how are the relevant topics changing? If you tracked the most active topics in conversations and channels over time you’ll have a map of topic change in a channel and start to see the things that matter to a community
  • How do I find a complicated answer without using exact text, like “when was the last time we talked about pricing” – mapping topics will help search by adding context to the conversation
  • Is there a way to flag information for curation in real time? If you have a simple bot that is a member of of a public channel, you could use emoji signalling to mark “this post is great” or “this post is making me angry” or simply analyze the map of reactions that happen to a post
  • Can I make search work better? Because search is fragmented, use the user’s credentials to search multiple channels and return by active conversation or by topic map
  • What happened this week? Because all instances look the same, make it memorable. Send an opt-in daily or weekly digest with a way to the day’s or week’s news. If you gave admins the ability to add content to the summary before it’s sent, this would give you another place to curate news.

Slack isn’t the only place where this happens, and it is one of the most accessible to automate. 

Here are a few teams working on this problem today (August 2020)

  • Get Lowdown is building daily digests of Slack;
  • Obsidian is creating a local graph database for notetaking and building a plug-in architecture for other apps as well;
  • Roam Research is creating auto-linking discovery and entity matching based on your notetaking; 
  • Scorebot is a Slackbot that measures and tallys emoji reactions to posts using a point total 
0

Thoughts on the Bus Problem

osman-rana-222325

(photo by https://unsplash.com/photos/HOtPD7Z_74s)

What’s the most important thing you do at work?

Most of us, when asked “how do you create job security”, default to explaining a way of interacting with others that only we can do. If you have unique skills, of course you would want to create a solution where you can solve the problem. It’s romantic to think that you – the cowboy or cowgirl – can race into the important situation and solve the problem where no one else can, or do it faster than anyone else.

Described differently, “I am the only one who can get it done on time and under budget” also looks a lot like “I am a bottleneck”, or “my company is now vulnerable to the ‘Bus Problem’, where if I get hit by a bus my company will have absolutely no way to do the things I know how to do. These statements now look a bit different.

A Corollary To What You Do Today

But what if creating personal job security looked completely different and had more to do with creating systems everywhere you go that help everyone else in the company raise their game? In this version of the bus problem, maybe the solution is to make bus schedules (so that all buses run on time), and develop contingency plans (like snow routes) for what happens when there is inclement weather or other unexpected behavior like traffic?

The best way to solve the problem of institutional knowledge sharing is to share that knowledge. Duh. But it means more than simply barfing out that information in whatever messaging suite happens to be the flavor of the month. True knowledge sharing means that you can isolate the facts and share the strategy implications of changing course, that you can write a procedure anyone in your company can follow, and that if you are not in the office the process works without you there.

What does this look like in practice?

Let’s say for the moment that you are responsible for updating the team on a new feature in your product. As a consumer of that information inside of the company, each person in each role needs something different. Sales might need to know if the price of that product changes or if specific customers had been waiting for it. Marketing might need to know if there are marketable features that could be shared with a wide audience. Engineers might want to know if there are new things to test and build. And Customer Support needs to know the typical things customers will ask and how to solve their problems.

Compare your original goal of becoming the only one who can solve a critical problem with the goal of sharing information with everyone in the company at the right time to ensure a productive product release. If you don’t create systems that ensure people on your team know what they need to know before you can tell it to them, you will fail. Your participation in the process should be the reinforcement of the knowledge, rather than the only way they know that information.

Start today by writing down an important thing that no one knows into instructions that person can follow, and then take the day off. Train a trusted resource, take the day off, and see how things went. If you get to “One in a Row” on this problem, you’re ready to tackle the next critical business process you own until the whole business can run without you telling them which buses run next on the schedule.

0

One of the most difficult product decisions is “not yet”


(Photo courtesy of https://unsplash.com/photos/3IVOgGIBsM0)
I recently had a (great) idea for a product. In my head it made perfect sense – a way to make it easier for people building presentations to get instant help from a trusted freelancer. Surely many people would be excited to try it out. 

The idea went from sketched-out prototype to tech exploration to see if it was possible to execute the thing I was thinking about, and two things happened. First, two very smart people asked whether this is a problem that anyone has,  and whether I had any data to prove the size of the market. Second, I realized I hadn’t done enough work to move from idea to execution.

“Of course,” I said, sharing market validation stats and thinking about channel partners. But then it hit me – I hadn’t yet taken the fundamental step to validating the market need by hand with no tech investment and no real effort spent. Ideas are a dime a dozen until they have some traction.

And it made me consider the optimal way of moving from idea to idea++, or taking the first next step toward validation. “Paper prototyping,” – the effort to simulate the experience of building product without actually building that product – is useful when combined with tests to establish demand. 

In this case, what was needed was a plan to ask people (ideally those I don’t know) to state that 1) they needed help with presentations and 2) that they are willing to pay other people to solve that problem.

One way to test that would be to use an existing site where people request freelance assistance (let’s say Fivvr, Upwork, or similar) and put up an ad for services. The responses to this ad would give one set of signals for demand. Then, the type of work that resulted might help me determine whether the initial hypothesis is worth more thinking. And third, the initial revenue would give clues to the potential profitability of the idea.

Do I know whether I have a great product idea? Not yet. The next step is to validate whether presentations made “good enough” are sufficient for most people, most of the time. If that’s the case, on to the next idea, until there’s a bit more signal that this one is more than a momentary aha!

0

When you get a chance to go back to a great team, jump at the opportunity!

23218164373_a0606175e1_k
courtesy of https://www.flickr.com/photos/hernanpc  

Have you ever been on a great team?

I mean the kind of team that people and alumni talk about years later. I’m talking about a team that produces results, leads the market, and is the kind of team that spawns other great teams. It’s hard to produce these kinds of results once, so it’s all the more remarkable when the same team produces another high-performing team (and highly correlated to success in the new venture)

In my career, I have been on great teams, and also participated in not-so-great teams.

Here are a few things that great teams do that mediocre teams do not do:

Great Teams Focus Their Efforts

In a startup (or really inside any company) there is always too much to do and almost always not enough time and resources to do it. Great teams build a culture where people focus on the next best thing they can do to improve the company, and make it easy for people to work together to gain results. For example, when you cut a lightly used feature and take the time to improve an existing feature, you are lowering the surface area of your product and helping the whole team to feel better about the quality of your software.

Mediocre teams work on many projects at once and never ship. On these teams, someone always claims credit for doing the work instead of giving kudos to another team member to congratulate them on a job well done. Mediocre teams endlessly add features without taking the time to ask customers whether the existing features meet their needs.

Great Teams Identify and Amplify Team Strengths

On a great team, it’s easy to find specialists. They are busy doing what they do best – not struggling at tasks they do the worst – and producing strong results. Some of the specialists have a specialty of getting other people to make decisions, push themselves to do new things, or to reduce the overall quantity of work to produce higher quality work. Great teams form around individuals who have strengths the whole team can use. These teams ask “how can I help?” to each other rather than saying “I’m too busy – can you ask someone else?”

On a mediocre team, it’s hard to determine what anyone does well, because everyone is meeting with each other in the same meetings. There is no time for work during the work day, because no one comes prepared to discuss items at meetings, and people spend the meeting time multitasking and doing the work they could not complete in their previous meetings. Mediocre teams leach away the strength of their individual specialists by creating an environment where no one knows how to make a decision and where no one feels empowered to ask for that decision.

Great Teams Are Resilient

Having a great team does not isolate you from conflict. Great teams are effective at meeting conflict head-on, discussing the problem, finding a solution, and then moving forward either by “disagreeing and committing” or by genuine consensus. These teams are resilient because during times of trouble team members lean on each other’s strengths and find solutions to seemingly intractable problems.

Mediocre teams fall apart or descend into chaos during stressful situations. There are few things more disappointing than thinking you’re on a great team, encountering a stressful situation, and then realizing your team is rather mediocre. Instead of the support you get from a great team, on a mediocre team it ends up being every person for themselves.

Great teams are hard to find.

I recently joined the team at Kustomer because this is a great team solving a hard problem in an important market – CRM for support customers – and I wanted to be part of that effort. So far, working at Kustomer feels similar to the atmosphere I shared with some of the team members when we worked together at Assistly. We work hard, we play hard, and we are building a business centered on our customers. But what makes a team great?

Great teams sometimes form by themselves and sometimes are made. People know a great team when they experience it. Great teams do not last forever, because culture is hard. When you get the band back together, it doesn’t always work. But when it does, it’s amazing.

Kustomer is a great team. We are crushing it. That doesn’t mean we’re always right – it means we are going after a great market with proven technology expertise, deep domain expertise, and a kick-ass attitude.

1

Blog at WordPress.com.

Up ↑

%d bloggers like this: