Конспект Intercom on Jobs-to-be-Done

When you’re solving needs that already exist, you don’t need to convince people they need your product. It’s easier to make things people want than it is to make people want things. 

Chapter 1: Focus on the job

Personas will always have their place. But if you want to build a great software product, making crucial decisions based around a series of personality traits won’t get you there. That’s because products don’t match people; they match problems.

If there are no key differentiators between all your users, you’ll end up with useless, vague personas. 

Some products are better defined by the job they do than the customers they serve. For some products, customers come in all shapes and sizes, from all countries, all backgrounds, all salaries, and all levels of computer skills. The only thing in common is the job they need to get done. In these cases, it’s best to get an intimate understanding of the job itself, what creates demand for it, and what you’d hire to do the job.

Chapter 2: Understanding your real competitors

So when you’re thinking about competitors, it’s best to ignore product categories and instead ask yourself who else is fighting for that same job.

In indirect competition, there are two different jobs a customer wants to do, but the jobs themselves are competing with each other. 

Your marketing should work to make the alternative outcome less attractive, or reposition your product so the outcome is no longer in conflict.

The point is, customers don’t experience your product in a vacuum. They experience it alongside every other product, service, and idea fighting for their attention. Some of these will compete with your brand and some will contradict it. Understanding all these forces helps you counter them with your marketing efforts.

Chapter 3: More than mattresses: using Jobs-to-be-Done research for software

Take enterprise software. From a lack of budget, to a change in management, to multiple tools being used for one job, many things factor into why a company might switch to a new product. These factors can be used in your interviews. Involve functional aspects from within a company, 15 along with emotional triggers from that time.

· What tool were you using before you bought <software>? Were you also involved in buying that?

· What was is it like working in <department> for <company> back then?

· Can you remember if anyone else was involved in the decision? What was their role in the company at that time?

· Tell me about the <old solution>. Can you remember how well that was working? Was it just your department using it?

The ReWired Group have identified four forces pushing and pulling customers away from making a purchase.

Our reasons for buying software can lean more toward business goals like increasing engagement or revenue, rather than personal goals like increasing overall happiness (though if software is well-designed, it can do both). You could argue for software, the purchase decision can be influenced by multiple previous purchases rather than just the push factors of the current tool. In a software scenario, the forces are:

· The push of what is happening currently: “We’re not converting users at a rate that we’d like. We can’t afford to keep paying so much per month for this tool.”

· The pull of a new solution: “If we switch to a new tool that has more features around conversion, we can start hitting our targets.”

· The anxiety of what could happen: “What if the new tool doesn’t integrate as well as we’d like? We’ve tried three other tools for this job and none have been good enough.”

· The attachment to what you currently have: “We’ve got workflows and integrations setup and it’d be a pain to get them set up again.”

The consideration set involves the time in which a person (or company) is looking at all the possible solutions for a job they want to fulfill through a product. It’s during this time “active” or “passive” looking takes place. Active looking usually stems from a moment of particular frustration the person has been through with the product. Passive looking can be ongoing for weeks/months while the person is uncertain if the product is doing its job well enough.

For software businesses, asking questions around the consideration set can help you uncover if there were situations where multiple people affected the purchasing decision:

· Once you figured out you wanted to buy a new solution, did you do much research to figure out which tool was right for your company?

· Were you the only one who was looking for something else at that time?

· Where did you first hear about the tool you picked?

· Can you recall how you came to purchase the specific tool you did?

· When you were looking around, did you (or anyone else) try out any other tools? What were they?

· How long did you look around before you clicked “buy” on the <tool’s> website?

Creating a timeline of events helps bring the interviewee back through their purchase journey. For software purchases, there are often multiple timelines at work.

This is down to there being numerous people involved in the decision to buy software. You’re really looking for the right people to talk to, the main decision maker. There are so many times you’ll hear: “I wasn’t at when we bought but I’m the main person who uses it!”

Unearth the main decision maker behind buying software by asking questions like:

· What year did <company> move to <product>? Were you there at that point?

· Who decided to make that move? Are they still at the company now? What role are they in? Knowing who the other decision makers are will give you a broader picture of where you need to innovate, and how you can support jobs your product is getting dropped for.

Chapter 4: Getting customers to switch

In short people rarely switch, but when they do, there’s an interesting set of dynamics at play. Whether it’s coffee or software most companies take the myopic route, and simply try to make their product look better than everyone else’s. The appearance of your product is only ever one part of what makes people switch.

Switching is also about removing fear or hesitation associated with trying out your product and making sure you remind them of the problems with their current solution. 

The way you motivate somebody to make a switch is the same for a friendship, a relationship, or a software product – identify the struggling moments your customers are experiencing and build around that. Emphasize why the existing way does not make sense, why it’s safe to switch to your product, and why they don’t need to worry about leaving the existing way behind. If you can solve all those things, you’ll get customers to switch.

To create an anxiety relievable only by a purchase…that is the job of advertising. Marketing increases familiarity, reminds consumers your product exists, and spreads product news. But marketing also does another job: it defeats inertia.

Advertising lets you manipulate these four forces. Specifically you can:

1. Increase the push away: Show how bad their existing product really is.

2. Increase your product magnetism: Promote how well your product solves their problems.

3. Decrease the fear and uncertainty of change: Assure consumers switching is quick and easy.

4. Decrease their attachment to the status quo: Remove consumers’ irrational attachment to their current situation.


Consumers overvalue what they already have by a factor of three, while companies overvalue their innovations, also by a factor of three. Here’s what it looks like:

When marketing your product, consider all four forces to win customers over. Often your product is more than good enough, but there’s another force blocking you. Advertise against that and you’ll see more movement.

Understand that consumers overestimate their current solution just as much as you overestimate the quality of your product. This means products with only marginal improvements don’t break through. The lead will only change hands when a 10X product arrives.

Chapter 5: Where one job stops and another starts

The most important thing a product manager does is decide where their product stops and someone else’s product takes over.

If your product does too little then it isn’t worth the cost of installation, let alone the actual purchase price. Similarly if a product does too much, it will clash with some other pre-existing software or workflow users are already happy with.

Start your product at the first step where you can add value. 

Your budget, whether time or money, should restrict but never define your scope. A large budget should define how well a problem is solved, never how many problems are tackled. Attempting to tackle an entire workflow from start to finish for all types of users is near impossible.

Your product should stop when the next step:

· has well defined market leaders looking after it (e.g. Apple, Netflix, Expedia), and you don’t intend to compete.

· is done in lots of different ways by lots of different types of users (e.g. trying to process salaries in a time-tracking app would be difficult).

· involves different end-users than the previous steps (e.g. managers, accountants, etc).

· is an area you can’t deliver any value.

Any time your user is clicking through a defined series of steps, adding no insight and making no decisions along the way, it’s a sign there are steps to be killed.

Always fill in the gaps before expanding the product. Expanding your product to solve a larger problem can work wonders, but can only be done on a solid foundation. If your fundamental product isn’t holistic, then adding more features only makes things worse.

There is a fundamental difference between making a product simple and making a simple product.

Making a product simple emphasizes removing all unnecessary complexity so every user can solve their problems as efficiently as possible. Making a simple product, however, is about scoping down and choosing the smallest subset of the workflow where your product delivers value.

This minimum viable product approach runs the risk of being labelled a point solution, or worse, “a feature but not a product”. When shooting for a “simple product”, be careful where you draw the line.

Chapter 6: A worse product can do a better job

Most products are obsessed with the intricacies of their own categories. But customers will always surprise you with the creative ways they use your product. They don’t do it deliberately – they’re just adapting your product to their needs.

When you focus purely on how a feature is used, ignoring the product category it’s in, or the type of feature it is, you quickly learn how to improve it. Rather than trying to address a hypothetical markets of would-be consumers, you can make improvements that resonate immediately.

Chapter 7: Abandoning personas: the story behind Job Stories

While best-in-class personas focus on goals (what drive people’s behavior) as well as attributes, the reality is that most personas focus on attributes alone, even when goal driven. So, it's almost useless.

The goals and attributes may look totally different, but their motivations are the same. Personas would never lead to the same product being designed and built for all audiences. 

Personas artificially break apart audiences. And critically, they artificially limit your product’s audience by focusing on attributes rather than motivations and outcomes.

Designing for motivation is far better than designing for attributes. It’s the key difference between personas and Jobs-to-be-Done. Personas look at roles and attributes. Jobs-to-be-Done looks at situations and motivations. Personas explain who people are and what people do. But they never fully explain why people do something. And why people do things is far more important.

While searching for people's motivation there are 2 challenges:

1. People are experts in their problem, not the solution. However, it is more natural to suggest a solution in the form of a feature request. Describing a suggested solution is easier than describing a problem, but you need to go back to them with questions to really understand their problem.

2. When they reply, their initial answer will tell you what they want, in the form of attributes, but not why that matters. So you need to keep digging into their motivations. So it was critical that we found out what problem our customers were actually trying to solve, and why they needed to solve it.

User stories are not empirically research driven, and are engineering driven, rather than customer driven. They are formatted to describe functionality to be built, rather than motivations people have.

Job Stories work better and focus on situations, motivations and outcomes:

“When ____” focuses on the situation, “I want to ____” focuses on the motivation, and “so I can ____” focuses on the outcome.

If we understood the situation in which people encounter a problem to 35 solve, understand the motivation for solving it, and understand what a great outcome looks like, we were confident that we would be building valuable product for our customers.

Chapter 8: Designing features using Job Stories

Here’s one approach on how a team implements Job Stories into their workflow:

1. Start with the high level job.

2. Identify smaller jobs that help resolve the high level job.

3. Observe how people solve the problem now (the job they currently use).

4. Come up with a Job Story to investigate the causality, anxieties and motivations of what they do now.

5. Create a solution which resolves that Job Story.

Designing successful products means observing how real people solve problems now, exploring the context of the situation they are in, and then understanding causality, anxieties and motivations.

Abstracted attributes and coupling implementation with motivations and outcomes are distractions for a team. If the team digs deep and learns about a customer’s Job-to-be-Done, they craft solutions more effectively. And using Job Stories to design products is one of the best ways to do it.

Chapter 9: Asking why the right way

When it comes to product design, there’s such a thing as getting down to the root problem too quickly. The value in figuring out the “Why?” behind things isn’t so much about the destination; it’s about the journey.

This is especially true for customer interviews. Slowing down, taking your time with each layer of the “Why?”, exploring lots of different ideas together; it all makes your time together much more productive. And it yields far more interesting and usable insights.

Here are the layers I’ve found the most valuable to fully explore:

1. The immediate layer relates to usefulness. What do you actually do with the thing? I use the drill to make holes.

2. The secondary layer relates to usability. What result comes from using it? I’ve made holes to hang photos.

3. The tertiary layer relates to desirability. What’s different now that I’ve accomplished my goal? I’ve hung photos and now have a more personal home.

When talking about the jobs a particular tool can do for a person, try not to rush to the ultimate, deepest answer. That isn’t always where the gold lies. Often, there isn’t just one root answer. Even if there is, it may not be all valuable on its own. Explore each layer thoroughly for the unique value it can provide.

April 25, 2019
by Анастасия Воронова
0
2

Конспект Intercom on Product Management

Chapter 1: Evaluate your product

When planning your roadmap, and where your team spend their time, it’s useful to ask “how many people are actually using each of our product’s features?”. Build a chart.

What do you do with your feature audit?

For any given feature with limited adoption, you have four choices:

  • Kill it: admit defeat, and start to remove it from your product.
  • Increase the adoption rate: get more people to use it.
  • Increase the frequency: get people to use it more often.
  • Deliberately improve it: make it quantifiably better for those who use it.

The two most popular ways to improve a product are to add new features, or to improve existing ones.

You can improve an existing feature in three different ways:

  • You can make it better (deliberate improvement).

Use it when there is a feature that all your customers use and like, and you see opportunity to add significant value to it. It’s worth noting that deliberately improving a well-adopted frequently used feature is high risk high reward.

  • You can change it so customers use it more often (frequency improvement).

Trigger: the reason the user goes to the product (e.g. you received an emailto say a contact had endorsed you for a skill).

Action: they take in anticipation of the reward (e.g. scroll, search, browse, etc).

Reward: the user gets from taking their action (e.g. seeing a beautiful Pinterest board).

Investment: the user makes which will plant the seed for more triggers (e.g. subscribe, pin, like, connect, etc).

Use it when there is a feature that the majority ofyour customers use infrequently, and you believe that using it more would be of benefit to them. It’s worth considering how your business will profit from this increased frequency.

  • Or you can change it so more people can use it (adoption improvement).

Adoption improvements target those who don’t use a feature. To get more people using it, rank and resolve the issues that are stopping them from using it. This is where the five whys technique is genuinely useful.

Use it when there is an important feature that a good chunk of your users have yet to adopt, and you see some obvious integrations or changes that will make it easier for them to get on board. When planning adoption improvements, always consider improvements outside of the software too. Sometimes it’s not about how the feature is designed or built, it’s about how it’s explained.

Chapter 2: When to say no to new features

If you focus only on new features you’ll build a product that is miles wide and inches deep. And if you focus only on repairs you’ll never innovate, thus becoming irrelevant.

When you are focusing on improving your product, a great question to ask is “Where do we suck, and where does it matter?”

Ullwick’s simple opportunity algorithm cleanly identifies the shortcomings in a product, by getting customers to rank the jobs they need to do by how important they are, and how satisfied they are currently. The opportunity is then simply expressed as:

importance + (importance – satisfaction)

Put simply: a minor improvement on an important task is almost always a larger opportunity than a big improvement on an ancillary one.

Product managers, or founders fulfilling that role, have to be great at saying no.

Avoid this points for adding new features as they leave you far away from a good product:

1. BUT THE DATA LOOKS GOOD - the interpretation is not always correct

2. BUT IT’LL ONLY TAKE A FEW MINUTES - there's no few minutes changes as it involve planning, explaining to customer and support

3. BUT THIS CUSTOMER IS ABOUT TO QUIT - what's good for one can be bad for the other

4. BUT WE CAN JUST MAKE IT OPTIONAL - it makes product too difficult

5. BUT MY COUSIN’S NEIGHBOUR SAID...

Ponts contr this:

  • what your product actually does.
  • whether your brother’s company are a good target customer.
  • whether they actually use it or just say they do.
  • and whether advanced segments are actually the right solution for what your customers are trying to do.

6. BUT WE’VE NOTHING ELSE PLANNED - than improve code

7. BUT WE’RE SUPPOSED TO BE ALLOWED TO WORK ON WHATEVER WE WANT

8. BUT 713,000 PEOPLE WANT IT - is this a valuable feature, within our purview, that all our customers will use?

9. BUT OUR COMPETITORS ALREADY HAVE IT - that doesn’t mean it’s a good idea

10. BUT IF WE DON’T BUILD IT, SOMEONE ELSE WILL - it's impossible to build everithing, but important to make a good product

11. BUT THE BOSS REALLY WANTS IT

12. BUT THIS COULD BE “THE ONE” - when you’re afraid to make hard decisions, you fall back on appealing to the unknown, and therefore building everything. You end up with a repository of features, not a product.

Chapter 3: Which new features to build

People don’t buy a product because they fall into a particular group. But they do buy a product to solve a problem. If you understand the “job” that customers are hiring your product to do, then you can make sure that you have a razor sharp focus on helping them achieve the desired result. The features you choose to build should be the ones that will help them do the job that needs to be done.

The problems people encounter in their lives rarely change from generation to generation. The products they hire to solve these problems change all the time. When you’re building or managing a new product, you have to believe you can create a better solution that people will want to use because it delivers a better outcome for them. A strong understanding of the outcome customers want, and how they currently get it, is essential for you to succeed in product management.

If you can’t find what product they’re currently using, the chances are that it’s a fictitious outcome.

Making things people want involves understanding a long standing human or business need and then using technology to:

  • take out steps.

Pick a need where the existing solutions are old, complex, and bloated, and find the simplest smallest set of steps possible to deliver the same outcome.

  • make it possible for more people.

The second approach usually involves reducing the cost (in time or money), or barriers to using a product so that more people can use it, thus expanding the market.

  • make it possible in more situations.

This approach involves removing common situational limitations on a workflow.

An acid test for new features:

1. DOES IT FIT YOUR VISION?

2. WILL IT STILL MATTER IN 5 YEARS?

3. WILL EVERYONE BENEFIT FROM IT?

4. WILL IT IMPROVE, COMPLEMENT OR INNOVATE ON THE EXISTING WORKFLOW?

5. DOES IT GROW THE BUSINESS?

6. WILL IT GENERATE NEW MEANINGFUL ENGAGEMENT?

7. IF IT SUCCEEDS, CAN WE SUPPORT AND AFFORD IT?

8. CAN WE DESIGN IT SO THAT REWARD IS GREATER THAN EFFORT?

9. CAN WE DO IT WELL?

10. CAN WE SCOPE IT WELL?

When you’re planning your next few months work, plot your features on this chart:

The trick is to plan your roadmap so there’s never long periods where customers feel the application has been abandoned. This is precisely where quick wins are useful.

A series of steps to progressively release it using feature flags:

1) Team testing

2) Company testing

3) Restricted beta

What you’re looking for here is:

  • Discoverability – are people finding this feature?
  • Engagement – are people using this feature?
  • Adoption – is it now being used as part of a workflow?
  • Use Cases – how is it being used? what use-cases are popular?
  • Barriers – Who isn’t using it? why? what’s preventing them?

4) Full roll out

Chapter 4: Getting that feature used

The majority of new features flop. You just don’t notice it happening. To prevent it, ask:

1. WILL EVERYONE SEE AND UNDERSTAND IT?

2. ARE YOU SHOWING USERS WHAT YOU DID, OR WHAT THEY CAN DO?

3. ARE YOU ANNOUNCING IT IN CONTEXT?

The right time to promote an improvement is when someone is in your product in a position to use it i.e. an in-app announcement that is triggered according to rules and events.

4. HOW WILL TOMORROW’S SIGN UPS HEAR ABOUT IT?

5. DO YOU PLAN TO FOLLOW UP WITH USERS & NON-USERS?

Once a feature is live, you should follow up with those who use it to understand how, why, and when it’s used. Look for ways to increase usage of it. Here’s some questions I’ve asked customers about a new feature:

When did you notice it? What did you think? Did you use it straight away? What attracted you to it?

  • Did you need to read the documentation? Was it sufficient?
  • Were there any barriers to you using it?
  • Are there times in your work day that you want to use this but can’t?
  • Have you told anyone about what you use it for? What did you say?

Here’s three ways to increase user engagement:

1. MAKE A STRONG FIRST IMPRESSION

The first screen your users see has three important jobs:

  • Explain how your application works.
  • Motivate your users to get started.
  • Let your users know how to get help, if and when they need it.

2. GRADUALLY EXPOSE THE DEPTH OF YOUR PRODUCT

Emails arrive out of context, out of time, and are more likely to interrupt a user than to interest them. It's better to create message schedules to gradually promote certain features. When you have good insight into your userbase you can work out which secondary features delight users and at what point they’re useful.

3. ANNOUNCE FEATURES AND IMPROVEMENTS IN-APP

Features struggle for adoption for lots of reasons, users don’t see the value in using it, they find it too complicated, it’s hidden somewhere clever in your product, they’re the wrong type of users, and dozens more. This is why it’s important to say no. When you’re faced with a feature that only 8% of your user base are using, you have to make a call: Kill it or Keep it.

Keeping a feature that has no adoption requires design and communication. You need to target the users who are using it, and work out why. Target some users who aren’t, and work out why.

April 22, 2019
by Анастасия Воронова
0
6

Конспект "Lean Customer Development: Building Products Your Customers Will Buy" by Cindy Alvarez

Глава 1: Что такое custdev и зачем его применять

CustDev - подход к пониманию:

  • кто клиенты продукта;
  • какие у них проблемы и потребности;
  • как они сейчас их решают;
  • за какие решения они готовы платить;
  • как делать эти решения подходящим для клиентов способом.

Подход работает для компаний любого размера и на любой стадии существования и помогает проверять гипотезы и создавать продукт на основании данных, полученных от клиентов, а не на субъективных догадках.

Глава 2: С чего начать

CustDev начитается с построения гипотез. Лучше всего в процессе брейншторма с командой, организованного как три упражнения:

1) Определить предположения.

В этом упражнении каждый записывает свои предположения о том, что верно для продукта и клиентов: какая должность и какой социальный статус у клиентов, какие у них проблемы и как они их уже решают, как на них повлияет приобретение продукта, чем он будет полезен, как клиенты принимают решения о покупке и что на них влияет. Цель - получить как можно больше разноплановых и не всегда очевидных ещё не проверенных догадок, на основании которого будут строиться гипотезы для проверки.

2) Записать гипотезы проблем.

Примерные формулировки проблем:

Я думаю, что [тип людей] сталкиваются с [такой проблемой], когда выполняют [такое задание].

Я думаю, что [тип людей] сталкиваются с [такой проблемой] из-за [таких ограничений].

Чем более узкая формулировка гипотезы, тем быстрее и проще её подтвердить или опровергнуть.

3) Описать клиента.

Необходимо определить примерный портрет клиента с помощью спектра черт, ему присущих. Для b2b продуктов можно выбрать следующие черты:

  • слабо владеющие технологиями Vs технически подкованные;
  • низкая Vs высокая автономность;
  • консервативная Vs прогрессивная корпоративная культура;
  • склонны Vs не склонны к риску;
  • ценят стабильность Vs восстанавливаемость;
  • предпочитают решения под ключ Vs лучшие на рынке.

А также следующие более общие вопросы:

  • Что больше всего беспокоит клиента?
  • Какие успехи или награды его наиболее мотивируют?
  • Какую позицию на работе он занимает и какие функции выполняет?
  • К какой социальной группе он себя относит?

Такое описание поможет построить структуру последующих интервью для проверки предложенных гипотез.

Глава 3: С кем нужно общаться

Пути поиска клиентов, которые могут рассказать о своих проблемах и способах их решения, ещё до релиза продукта точно такие же, как и после него:

  • поиск релевантных площадок для рекламы;
  • поиск потенциальных заинтересованных людей, демонстрация им продукта, эскизов;
  • поиск площадок, где уже обитают потенциальные клиенты, и попытка размещения на них;
  • кросс-реклама с комплиментарными продуктами и услугами;
  • создание веб-сайта для мониторинга каналов, из которых приходят клиенты.

Для опросов подходят те люди, для которых продукт выгоден, то есть, они страдают от его отсутствия, поэтому будут рады помочь в его формировании именно таким, чтобы он решал их конкретные проблемы.

Для этих клиентов помощь - не одолжение, а взаимовыгодное сотрудничество.

Мотивация клиентов давать обратную связь по продукту:

  • нравится помогать людям - мотивация активируется персонализированным обращением с просьбой об индивидуальной помощи, а не к неопределенно большому кругу лиц;
  • нравится, когда их считают умными, - начиная беседу с пользователем, мы подтверждаем, что считаем их экспертами и хотим научиться чему-то из их опыта;
  • нравится чинить и исправлять - рассказывая о своих проблемах, клиенты находят выход негативным эмоциям и чувствуют облегчение, а продолжая беседу по продукту, чувствуют, что проблема может быть решена.

Как искать потенциальных клиентов для опросов?

1) Список контактов

Начать поиск клиентов можно со своего списка контактов: посмотреть, есть ли там потенциальные клиенты или те, кто могут представить другим знакомым, которые могут быть потенциальными клиентами.

Необходимо максимально упростить этот процесс для помогающего человека:

  • отправить письмо, которое можно легко переслать, даже если только что поговорили голосом;
  • четко сформулировать, кого вы ищете, какую информацию и для чего хотите получить.

Примерная структура письма:

  • сформулировать проблему, над которой вы работаете;
  • выразить уверенность в том, что адресат может помочь, есть нужные контакты в нужной сфере;
  • уточнить, не возражает ли адресат переслать письмо/представить вас;
  • пояснить, как это важно и может сильно помочь вам;
  • попросить переслать это сообщение;
  • включить готовое сообщение, которое легко переслать, указав в нем, что вы ищете, сколько потребуется времени.

2) LinkedIn

Используя поиск и фильтры, можно находить нужных людей по их должности: писать своим контактам, просить своих контактов представить вас их контактам, которые для вас контакты второго уровня, писать сообщения InMail для премиум аккаунтов.

Здесь лучше писать короткие сообщения, четко пояснять, почему этот человек может вам помочь, над какой проблемой вы работаете и сколько времени займет опрос.

Лучше делать небольшие предварительные опросы для того, чтобы отсеять нерелевантные контакты.

3) Quora

Аудитория Quora гораздо меньше, зато более склонна к высказыванию.

Чтобы общаться с пользователями, нужно иметь заполненный профиль и желательно быть активным пользователем. Лучше не создавать обсуждения с выпрашиванием, а писать в директ.

4) Другие тематические форумы

5) Оффлайн

Можно использовать места большого скопления потенциальных клиентов или тематические конференции для общения. Важно не прерывать людей в процессе дел и не рассчитывать на длинные интервью.

6) Блоги

В агрегаторах блогов, например, alltop.com, blograma.com, blogs.com, а также в поисковике можно найти блоги на релевантные темы и связаться с их автором.

7) Twitter

Проще работать с твиттером, имея конкретную аудиторию, однако можно общаться с конкретными людьми посредством упоминаний, искать людей, информацию или ивенты с помощью хештегов.

8) Лендинги

Можно создать лендинг и закупать на него трафик на AdWords. Это дорого, если ниша не узкая.

Преимущество лендинга - составление опросников, которые вызывают больше доверия, чем созданные через специализированные сервисы, и, как следствие, конверсия ответов выше.


Как проводить интервью

1) Дома или в офисе клиента - можно получить подробную картину и установить более тесные отношения, но их сложнее организовать. Подходят для:

  • компании с уже существующими продуктами и клиентами;
  • проблемы, в которых окружающее пространство имеет значение;
  • проблемы, вовлекающие множество заинтересованных сторон;
  • продукты, используемые дома.

2) Личная встреча в нейтральном месте - плюсы и минусы как и в предыдущем методе. Подходят для:

  • интервью с несколькими людьми, чтобы при этом их не отвлекали;
  • потребительских товаров, аудитория которых достаточно широкая.

3) По телефону - более быстрые, люди могут быть более откровенны, когда отсутствует визуальный контакт, при этом по интонации всё равно проясняют картину, никуда не нужно ехать, проще добиться согласия на интервью, проще делать пометки. Подходят для:

  • связи с занятыми людьми;
  • разговора с пользователями с разным местонахождением и временными зонами;
  • совершения максимально большого количества интервью за минимальное время.

4) Видеозвонки и транслирование экрана - преимущества как и в предыдущем способе. Подходят для:

  • технически подкованной аудитории, видеосвязь для которой не вызывает проблем;
  • интервью, в которых необходимость видеть экран клиента критически важна.

5) Мгновенные сообщения - всегда риск недопонимания, не дают эмоциональной информации. Подходят для:

  • клиентов, для которых разговор голосом менее комфортный (застенчивые люди, клиенты с акцентом или которые хотят больше контролировать информацию, которую они сообщают);
  • интервью, в которых важно обмениваться такими данными, как URL или сниппеты кода.

При назначении интервью нужно сделать письмо максимально удобным для принятия решения клиента. Нужно предложить несколько вариантов времени, прислать инвайт, напомнить об интервью в день интервью.

Лучше не назначать интервью одно за другим, чтобы учесть возможные задержки, переключение между разными контекстами и записи после интервью.

Если на письмо с назначением интервью не отвечают, через 5-7 дней можно написать ещё раз, но не более того, чтобы не быть навязчивым.

Если интервью срывается, через пару дней можно предложить переназначить его, но не более одного раза, чтобы не быть навязчивым.

Глава 4: Что нужно изучать

Типичный скрипт для интервью с клиентом:

  1. Tell me about how you do ______ today?
  2. Do you use any [tools, products, apps, tricks] to help you get _____ done?
  3. If you could wave a magic wand and be able to do anything you can't do today, what would it be? Don't worry about whether it's possible, just anything.
  4. Last time you did ______, what were you doing right before you got started? Once you finished, what did you do afterward?
  5. Is there anything else about ______ that I should have asked?

Другие вопросы, помогающие направлять беседу:

  • Can you tell me more about how this process goes?
  • Who is involved in making that decision?
  • Last time you did _____, how long did it take?
  • Where did you most recently go to buy ____?
  • May I ask, why did you come to this conclusion?

Клиенты маловероятно могут точно сказать, чего они хотят от продукта, но от них можно получить информацию об:

  • ограничениях во времени, ресурсах, которые влияют на них;
  • их прошлом неудачном опыте;
  • средствах и процессах, которые они используют;
  • их потребностях.

Тем не менее, без специальных направляющих вопросов они об этом не расскажут, потому что это не всегда очевидно, воспринимается как должное. Поэтому нужно задавать вопросы и уводить от поверхностных ответов, узнать детали о том, почему те решения, которые они использовали, не сработали, раскрепостить клиента, чтобы ему было комфортно быть честным и откровенным.


В ходе интервью нужно сконцентрироваться на получении следующей информации:

1) Что клиент уже делает - что он способен делать, что ему комфортно делать и почему, какие решения он принимает.

В этих вопросах важно абстрагироваться на уровень выше в проблеме, которую вы хотите решить, чтобы не ограничивать пользователя в ответе на вопрос. Например, спросить не о том, как он загружает и делится документами, как что он делал в последний раз, когда работал над документом и ему нужна была совместная работа над ним с коллегами.

Важно:

  • Фокусироваться на процессе, а не результате, чтобы не упустить комплекс факторов, возможности и ограничения, опыт клиента, которые влияют на принятие решения, то есть, на результат. Нужно быть готовым задавать уточняющие открытые вопросы о деталях, подробности которых клиент опускает как нечто естественное.
  • Фокусироваться на настоящем, а не будущем, так как люди склонны идеализировать свое будущее поведение. Поэтому, вопросы должны быть о том, как клиент делал что-либо в последний раз, в прошлом месяце и так далее.

2) Какие ограничения сдерживают клиента - часто кажется, что клиентов останавливает только то, что у них нет этого продукта, или то, что нет желания его искать. На деле же ограничений гораздо больше, они не все объективны, но от этого не менее весомые. Среди них:

  • Проблема не воспринимается как проблема.

Выполняя задания, мы фокусируемся на том, как выполнить его, а не как оптимизировать нашу работу по выполнению задания.

Чтобы изменить такое восприятие, нужно попросить клиентов декомпозировать процесс, описать последовательность действий, компоненты. Это заставляет задуматься о том, сколько времени и усилий они тратят на это задание, осознать, что каждое действие является не чем-то неотъемлемым, а выбранным ими решением, и что, возможно, существует и лучшее решение.

Другой способ - сравнить этот процесс с тем, каким он может быть в будущем, когда проблема будет решена, не вдаваясь в подробности продукта, а погружаясь в проблемы, которые это действие вызывает сейчас.

  • Недостаток осведомленности о том, что технически возможно.

Клиентов сложно вытянуть из реальности, чтобы они сформулировали решение. Вопрос с "волшебной палочкой" снимает напряжение и порождает креативные идеи. Их можно интерпретировать в фичи, которые можно создать.

  • Ограниченные ресурсы: окр.среда (пространство, шум, плохой интернет, руки заняты и т.д.), время, бюджет. Важно понять, какие именно ресурсы влияют на клиента.
  • Культурные и социальные ожидания, которые ограничивают поведение.

Существуют негласные корпоративные правила, из-за которых клиенты могут бояться использовать продукт и потерпеть неудачу или не могут использовать его без разрешения начальства.

Также использование продукта может противоречить тому, как клиент хочет видеть себя, так как использовать продукт означает признать, что у клиента есть какие-то недостатки. Это не всегда очевидно для самого клиента, можно попросить смоделировать ситуацию, в которой клиент будет использовать продукт, и понаблюдать, не выдает ли язык тела и голос клиента, что ему некомфортно.

3) Что расстраивает и мотивирует клиента - люди не принимают только лишь рациональные решения, всегда есть набор факторов, которые вызывают дискомфорт и приводят к решениям, которые объективно не кажутся рациональными. Важно понять эти факторы в ходе интервью.

Наиболее демотивирующим обычно людям кажется неопределенность: когда непонятно, как это работает, как использовать продукт лучше всего, что делать, если что-то пойдет не так.

Также важно понять, что его радует больше всего, благодаря чему он чувствует себя успешным.

4) Как клиент принимает решения, тратит деньги и определяет ценность - часто в процесс приобретения, оплаты и использования продукта вовлечены разные лица. Важно понять всю цепочку в процессе интервью.

Возможными заинтересованными сторонами могут быть:

  • дети и супруг (желание минимизировать конфликт);
  • социальное окружение (желание избежать осуждения);
  • тот, у кого деньги\платежные реквизиты;
  • люди, которые предоставляют дефицитные и необходимые навыки, такие как команда технарей или юристов;
  • люди, которые проводят комплаенс (IT, юристы, финансисты);
  • люди, которые используют продукт вместе с клиентом (для продуктов, для которые требуется коллаборация или совместное использование).

В целом, не нужно спрашивать клиента о его качествах, то есть, о субъективной оценке самого себя. Нужно спрашивать об объективных вещах и делать выводы из его субъективных ответов.

Глава 5: Практика интервью

Перед первым интервью полезно провести пробное интервью.

При введении записей нельзя обобщать сказанное, так как можно потерять суть. При custdev в процессе интервью мы ещё не знаем, что важно, а что нет.

Наиболее детально нужно записать:

  • то, что подтверждает гипотезы;
  • то, что опровергает гипотезы;
  • все, что застало врасплох;
  • все, что наполнено эмоциями.

Парное интервью позволяет сконцентрироваться на клиенте, получить обратную связь от коллеги по поводу техники проведения интервью.


До интервью необходимо навести справки о клиенте: его должность, социальный статус - то, что имеет значения для продукта.

В самом начале разговора необходимо:

  • уверить клиента, что он сможет помочь;
  • пояснить, что в основном будет он говорить;
  • сделать, чтобы он говорил.

Можно начать со стандартного скрипта:

Hello, this is [Name] from [Company]. Is it still a good time to talk?

Great! First of all, I'd like to thank you for talking with me today. It's incredibly valuable for me to get to listen to you talk me through your personal experience and how things work (or don't work) in your world, so I'll mostly be listening.

Could you start by telling me a bit about how you [perform general task] currently?

Важно:

  • поддерживать разговорный тон;
  • персонализировать себя;
  • подчеркивать важность лично опыта клиента.

Чтобы побудить говорящего говорить и давать детальную информацию, после первого заданного вопроса хотя бы минуту нужно не задавать других вопросов. Неловкое молчание заставит клиента говорить больше, а переход к следующим вопросам покажет, что вам достаточно сжатых ответов на 1-2 предложения.

Далее не нужно злоупотреблять этим приемом, чтобы не быть слишком холодным.

Нужно задавать уточняющие вопросы, побуждающие рассказать более детально. Вопросы должны быть открытыми. Даже к твердым ответам, в которых, казалось бы, клиент рассказывает, что он качественно решает какую-то проблему, можно задать вопрос о том, когда в последний раз ему нужно было ее решать, и, таким образом, узнать о каких-то проблемах, с которыми он столкнулся, но они не лежат на поверхности.

Стоит избегать вопросов, на которые можно ответить "да" или "нет". Они влияют на мнение клиента и искажают его.

Перед тем как перейти к следующему вопросу полезно повторить сказанное клиентом обобщенно. Это поможет подтвердить, что вы правильно всё поняли, а также может побудить к новым деталям, которые клиент не упомянул ранее, но могут быть очень важны.

Описывая проблему, чтобы перейти от её симптомов к самому корню, полезно использовать технику "5 почему".

Если клиент начинает отклоняться от темы, описывая другую проблему, нужно выслушать его и задать уточняющие вопросы. Вероятно, другая проблема волнует его больше. Это может стать новой возможностью для продукта или для нового продукта. Но возможно, он просто занимается не той частью процесса, которую вы изучается, и может порекомендовать вам кого-то другого для интервью. В таком случае, нужно вежливо пояснить ему, что вы не хотите тратить его время и что, возможно, в будущем будете исследовать эту проблему и обратитесь к нему, а также спросить, может ли он вам посоветовать другого человека.


Важно избегать такого хода беседы, когда клиент начинает говорить конкретно, что он хочет, рисовать макеты или составлять список фич. Важно понять, не что клиент хочет, а как он действует, и что ему нужно.

Чтобы вернуть разговор от фичи к проблеме, нужно попросить описать, как именно и когда клиент будет ее использовать, переформулировать описываемую ситуацию и попросить больше деталей.

Проблема неэффективности списков фичей от клиентов заключается в том, что предлагаемые клиентами решения лежат в плоскости их восприятия, искаженного решениями, которые уже есть, а они не всегда лучшие. Вопрос с "волшебной палочкой" помогает выйти за рамки этого восприятия и достучаться до более глобальной проблемы, которую пользователь не может решить и не представляет, как это возможно. Можно пояснить вопрос следующей фразой:

In the past, we've worked on products that were supposed to do something specific, but they didn't solve the real problem. We're trying to avoid that and make sure we build something that will help with your situation and address the things that make your life harder.

Лучше не показывать клиенту продукт или макеты, по крайней мере до конца интервью. Иначе его восприятие будет искажено, а ответы будут базироваться на том продукте, который у вас есть.

Не стоит затягивать интервью дольше, чем на 20 минут. Лучше попросить о повторной встрече.


В конце интервью нужно:

  • предложить свое время клиенту (ответить на вопросы);
  • дать клиенту почувствовать, как он преуспел в помощи вам;
  • лично поблагодарить за уделенное время.

Пример фразы для окончания разговора:

[Name], I think you've answered all the questions I had. Is there anything I can answer for you?

[Pause, answer the questions as needed]

Thank you so much for talking with me today. It was really helpful for me to hear you talk about [repeat a problem or situation the interviewee discussed]. That's the type of detail that it's just impossible for me to learn withiout talking to real people who are experiencing it.

Can I keep you in the loop as I continue to learn more? If I have further questions, or once I'm closer to building an actual solution, can I get back in touch with you?

[Pause]

Thanks again, and have a good rest of your day!

После окончания интервью важно вспомнить основные моменты о том, хорошо ли оно началось, отвечал ли клиент на вопросы развернуто и активно, не подавляли ли вы его своими вопросами, что вызвало у него больше всего эмоций, было ли что-то, что вы хотели обсудить, но не добрались до этого, и как добраться в следующий раз.

Глава 6: Как выглядит подтвержденная гипотеза

В интерпретации результатов интервью нужно придерживаться здорового скептицизма.

Людям свойственно высказываться более оптимистично:

  • они могут говорить то, что вы хотите услышать, чтобы не расстроить вас, а в случае с b2b продуктами, имеют склонность быть более дипломатичными, чем честными;
  • они могут говорить не о реальном, а о желательном.

Важно получать информацию о том, как люди ведут себя сейчас, а не хотят вести или думают, что так вести себя правильно. Иначе они не станут вашими клиентами, потому что для них приобретение продукта - не просто вложение денег, но и изменение привычного поведения, а это гораздо сложнее. Поэтому, услышав какое-то утверждение, нужно уточнить, что конкретно он для этого сделал вчера\на прошлой неделе.

Сравнение реальных и желаемых речевых паттернов:

  • Реальный

- I've already tried...

- Here is how I do...

  • Желаемый

- Plan on doing...

- Haven't tried yet...

- Keep meaning to...

  • Реальный

- I need to be able to do [task] faster\better because

- Here are the things making it difficult for me to do [task] currently..

  • Желаемый

- [Task] is impossible....

- I just don't know how anyone does [task]...

  • Реальный

- This would help me to achieve [goal]...

- If I had this, here's what I could do...

  • Желаемый

- I wish I had...

- It'd be interesting to see...

- Well, once I had it, I'd be able to figure out how to use it...

  • Реальный

- Right now...

  • Желаемый

- Soon...

- As soon as [some event happens]...

- Almost ready to...

  • Реальный

- Here's how I do...

  • Желаемый

- I don't! I really should do...


Ведение записей важно систематизировать:

  • Один документ с шаблоном для всех интервью;
  • Один документ для выводов для всех интервью.

Важно писать выводы, чтобы всей команде и вам не нужно было перечитывать все интервью, также это более наглядно систематизирует полученную в процессе custdev информацию.

Структура вывода может включать 5-7 заключений в формате:

  • validates;
  • invalidates;
  • also interesting.

Лучшие способ донести результаты своих исследований - вовлечь команду в процесс:

  • проведения интервью;
  • категоризации фидбеков;
  • обсуждения (путем задавания вопросов для размышления, а не выдавания готовых решений.

Важно участвовать в принятии решений при приоритизации продукта, а также понимать, что остальные участники команды и руководство не находятся в вашем контексте.


После 2-3 проведенных интервью необходимо проанализировать информацию, чтобы понять, что вы выбрали верное направление, точнее, не абсолютно неверное направление.

Компоненты подтвержденной гипотезы:

  • клиент подтверждает, что действительно есть проблема или болевая точка;
  • клиент верит, что проблема может и должна быть решена;
  • клиент активно инвестирует время, деньги, усилия, изучение в попытки решить эту проблему;
  • у клиента нет обстоятельств вне его контроля, которые мешают ему попытаться решить проблему.

После 2-3 интервью нужно попытаться ответить на следующие вопросы:

  • Если бы продукт был уже прямо сейчас, вижу ли я какие-то препятствия, из-за которых клиент не будет покупать или использовать продукт?
  • Как клиент будет использовать продукт, и как он подойдет его ежедневным активностям?
  • Что он заменит?
  • Если клиент не купит продукт, какие будут причины для этого?

Если на эти вопросы нет ответов, нужно скорректировать вопросы для интервью.

После 5 интервью вам должен попасться хотя бы один человек, для которого близка проблема, которую вы исследуете. Если нет, то это из-за того, что:

  • вы говорите не с тем человеком - возможно, вы неверно выбрали целевую аудиторию для своей гипотезы;
  • ваша проблема на самом деле не проблема - это не связано с неправильными вопросами в процессе интервью, по-настоящему взволнованный проблемой человек сам ответит на те вопросы, которые вы должны были задать.

Это означает, что гипотеза не подтверждена. Нужно выбирать новую и начинать сначала.

После 10 интервью должны сложиться определенные паттерны - концепты, которые вы услышали от нескольких людей.

Эти паттерны нужно тестировать на других клиентах, но не задавая закрытые вопросы, которые сделают интервью предвзятым.

Чтобы протестировать паттерн, нужно переформулировать его так, чтобы он приобрел противоположное значение, при этом лучше ссылаться на неопределенный круг лиц "другие люди", которые якобы придерживаются такого мнения, которое является противоположным найденному вами паттерну. Это побудит клиента к сравнению себя с "другими людьми" и описанию самого себя в сравнении с ними.

Если паттерна нет, то есть, вы получили несколько в целом похожих заключений, но не складывающихся в определенный паттерн, значит, вероятно, вы выбрали слишком широкий круг людей для интервью, и нужно попробовать его сузить по каким-либо параметрам.

Достаточное количество интервью достигается тогда, когда вы перестаете слышать то, что вас удивляет, интервью становятся довольно предсказуемыми. Это количество зависит от вашей индустрии, опыта проведения интервью, сложности бизнес-модели и затрат на воплощение MVP. При должном опыте чаще всего требуется 15-20 интервью.

Глава 7: Какой MVP нужно создать

Подход, в котором MVP - конечный продукт с урезанной функциональностью, не совсем верный, так как он концентрирует команду на том, что неправильный выбор фич - единственное препятствие для продукта. На самом деле проблема может заключаться в каналах распространения продукта, соотношении цены с качеством, возможности работы с ресурсами и партнерами.

Поэтому MVP должен лишь подтверждать или опровергать ваши гипотезы и давать ответы на вопросы:

  • можем ли мы достучаться продуктом до ЦА;
  • хотят ли клиенты платить за ценность, которую этот продукт обещает;
  • как клиент измеряет ценность, получаемую от этого продукта;
  • какая ценовая модель сочетается со значимостью продукта для клиента и его способностью платить.

Виды MVP:

Pre-Order MVP - представление решения с возможностью предзаказа и подписки. Помогает проверить, готов ли кто-то купить продукт, даже когда его ещё нет. Хорошо работает для:

  • решений, требующих критической массы пользователей для их поддержания и прибыльности;
  • решений, требующих существенных затрат времени и ресурсов для создания.

В целом, этот тип подходит почти для всех компаний.

Audience Building MVP - сначала создание комьюнити из ЦА, отслеживание их активности, затем презентация им продукта. Хорошо работает для:

  • онлайн-продуктов и сервисов;
  • бесплатных продуктов или изначально социальных продуктов;
  • команд с изобилием контента;
  • консалтинговых бизнесов, желающих расширяться в более масштабируемые продукты и сервисы;
  • аудиторий, которые больше защищают свое время, чем деньги.

Concierge MVP - предоставление сервиса вручную отдельно каждому клиенту. Этот подход плохо масштабируется, но помогает лучше понять проблемы клиента, его ход мышления, потребности и создать более подходящий продукт с меньшими затратами. Хорошо подходит для:

  • офлайн и не подкованных технологически аудиторий;
  • решений, для которых сложно предсказать логистику;
  • капиталоемких для масштабирования операционных инвестиций решений;
  • продуктов или услуг, в которых личное удовлетворение каждого пользователя - конкурентное различие.

Wizard of Oz MVP - также ручной сервис, который маскируется под автоматический, то есть, для пользователя это выглядит как обычный сайт, на самом деле процессы, происходящие на нем, выполняются вручную. Хорошо подходит для:

  • решений, требующих сложных алгоритмов или автоматизации;
  • потенциально чувствительные области проблем (финансы, здоровье, свидания, закон);
  • двусторонних рынков, где с помощью MVP можно симулировать одну из сторон для другой.

Single Use Case MVP - продукт или сервис, который может выполнять только одну функцию. С таким продуктом люди будут часто жаловаться на отсутствие недостающих функций. Это хорошо, так как означает, что к продукту есть интерес. Если жалоб нет, значит продукт не предоставляет ценности для клиентов. Хорошо подходит для:

  • существующих продуктов и компаний, которым нужно подтвердить изменение направления или ответвление продукта;
  • попыток войти на рынок, доминируемый большим, более сложным и более дорогим продуктом;
  • проверки, как продукт может принести наибольшую пользу для клиентов.

Other People's Product MVP - создание продукта с помощью других продуктов. С таким подходом MVP выглядит как новый самостоятельный продукт, но на самом деле для его работы используются уже существующие продукты конкурентов. Хорошо подходит для:

  • выхода на рынок с признанными конкурентами;
  • решений, в которых сложно предсказать логистику;
  • команд с ограниченными инженерными ресурсами.

Конечным результатом будет понимание того:

  • какие гипотезы были подтверждены;
  • какие нет и почему;
  • что клиенты думают о продукте;
  • какие новые гипотезы можно построить.

Глава 8: Как проводить custdev, когда уже есть клиенты

Многое из того, что могут позволить себе стартапы, неприменимо для компаний с уже существующими клиентами и продуктами.

Некоторые приемы, чтобы не рисковать клиентами.

Адаптируйте MVP концепцию:

  • вы уже преодолели риск того, что продуктом совсем никто не будет пользоваться, и теперь нужно выжать максимум из MVP;
  • все должно работать корректно;
  • используйте скетч или мокап для теста, чтобы он не был похож на настоящий функционал вашего продукта;
  • используйте другой домен;
  • MVP должен быть больше жизнеспособный, чем минимальный;
  • хорошо, если клиенты жалуются, это признак интереса, но полное разочарование - плохой сингал.

Найдите правильных клиентов:

Правильный клиент - не всегда самый прибыльный или брендовый, а тот, который больше всего получает ценности от вашего продукта и будет разочарован его отсутствием.

Таких клиентов можно найти с помощью опросов типа "как бы вы отнеслись к тому, что не смогли бы больше пользоваться продуктом". Те, кто отвечают "очень разочарован" - те, кто вам нужен. Их также можно искать путем аналитики и выбора наиболее активных пользователей.

С другой стороны, такие клиенты могут опасаться изменений, поэтому также полезно общаться с совсем новыми клиентами, которые пока не так плотно "вписали" вас в свою жизнь.

То, как клиенты, получающие пользу от продукта, его описывают, - ключ к тому, как этот продукт позиционировать и представлять другим клиентам. Как правило, клиенты говорят не о фичах и технологиях, а о своей пользе, прибыли, эмоциях. Шаблон для опросов, помогающих выяснить эту информацию:

  • How likely would you be to recommend us?
  • Who would you recommend us to?
  • Imaging you're speaking to them. How would you describe us to them?

Общайтесь и представляйте новые продукты:

При общении с клиентами важно управлять ожиданиями: ясно доносить, что предмет обсуждения - лишь идея, концепция, которую вы исследуете, чтобы понять, что действительно нужно клиенту.

Поэтому желательно не преподносить какие-то визуальные макеты и решения: они будут восприняты как уже реальные, их будут ожидать и меньше критиковать в процессе разговора из вежливости.

Если демонстрации всё же не избежать, то можно сделать кликабельный макет и преподнести его в формате сторителлинга: взять какого-то абстрактного человека и рассказать, как он будет пользоваться этой функциональностью.

Важно для демо:

  • определить ключевые фичи или концепции, которые нужно подтвердить;
  • написать скрипт использования фичи, приземленный на реальные события;
  • построить связанный прототип по всем шагам истории использования фичи.

Инкогнито custdev

Такой способ может быть полезен для компаний с консервативными клиентами, отвергающими все изменения. Есть два варианта реализации: либо вы представляетесь как сотрудник другой компании, либо вы общаетесь не со своими клиентами, а с:

  • сотрудниками, которые не участвуют в принятии решения о покупке продукта, но знают весь процесс изнутри;
  • клиентами, которые вам не платят;
  • клиентами ваших клиентов для получения инсайдов, которые могут повлиять на принятие решения вашими клиентами.

Демонстрации клиентами того, как они используют продукт

Этот процесс важен для поддержки существующих продуктов. Работает в решении проблемы непонимания того, как клиенты используют продукт, какие проблемы решают и почему уходят.

Начать демонстрацию можно с краткого объяснения, зачем вам это нужно:

As we've talked with our customers, one of the thing we have found most valuble is to watch exactly how people are using our software. So I'd like for youu to show me exactly what you do when you use our product. If there are times when you'd stop and do something else, or include someone elso to helpp or see something, let me know as we go.

How often do you typically use our software?

What are you usually trying to accomplish when you start to use our software?

OK, can you go ahead and start doing that task? Try to think out loud as you go, and describe what you're doing.

Здесь важно соблюдать баланс между молчанием и разговором, но не подсказывать клиенту и не исправлять ошибки, а задавать вопросы.

Если клиент начинает предлагать фичу, можно сказать, что вы это записали, и попросить подробно рассказать, как он будет ее использовать и для чего.

Что нужно выяснить в ходе разговора:

  1. Как часто и каким способом клиент использует продукт - иногда часто не означает, что продукт представляет ценность. Важно обращать внимание на то, какие проблемы и насколько эффективно клиент решает с помощью продукта, чтобы понимать, легко ли он заменим для клиента.
  2. Что он делает сразу после использования продукта.
  3. Как продукт совпадает с рабочим процессом клиента - вовлекаются ли другие люди, разбиваются ли процессы продукта в несколько этапов, нужно ли получать одобрение от менеджера в процессе использования.
  4. Сколько фич и какие фичи не используются.
  5. Новые возможности сделать продукт более ценным для клиента.

Демонстрации как использовать продукт новым клиентам

Если продукт многофункционален, многие фичи не используются или клиенты часто не продляют лицензии, можно проводить им демонстрации того, как использовать продукт.

Способ менее информативен для компании, но если поощрить клиента не соглашаться с вами в процессе разговора, то можно получить много инсайдов о том, почему клиенты не используют фичи. Возможно, они не нужны или непонятны.

Что нужно выяснить в ходе разговора:

  1. Ограничения клиента, о которых вы не знали.
  2. Прояснить ценность функциональностей продукта.
  3. Понять, почему неиспользуемые фичи не используются.

Глава 9: Непрерывный custdev

CustDev - не тот процесс, который нужно планировать, его можно делать непрерывно каждый день.

Техподдержка и отдел продаж - ресурсы компании, которые можно направить на custdev: когда у клиента появляется запрос или проблема, нужно расспросить его подробнее о том, зачем ему нужна та или иная функциональность, в процессе чего он столкнулся с проблемами.

Другой подход - спрашивать у наиболее активных клиентов, как бы они описали ваш продукт другим: это помогает понять, что представляет наибольшую ценность для клиента.

Также можно проводить опросы прямо в email, в которых общаетесь с клиентами. Просто в конце беседы добавить дополнительный вопрос.

Важно понимать, что многие клиенты просят схожую функциональность, но на самом деле пытаются решить разные проблемы. И наоборот: описывают разную функциональности для решения одной проблемы. Важно дополнительными вопросами докопаться до этого.

Важно делиться результатами custdev со своей командой в формате: вот что мы изучили, вот что мы сделали, вот какие результаты это принесло. Этой информацией можно делиться и с пользователями.

April 12, 2019
by Анастасия Воронова
0
40
Show more