How to Get to Know Your Users by Google former PM Vikram Chatterji
3 sections:
Why should you get to know your users right
When in dev cycle is it really crucial and important for you to keep a pulse on who the users are and what their pain points are
How do you do that? Where are the tools that you can use in order to really get to know who your users are
To think about why, we look at 5 quick examples:
Virgin Atlantic: case study
DoorDash: origin story- had an idea of how they can improve merchant operations for restaurants within restaurants. But true need from restaurants is managing logistics of taking their product from point A to point B to the customer. pivoted and changed value proposition, talking to over 250 customers in course of a month. That helped them what their strategy was going to be, who their customer segment is supposed to be and how they can really focus towards those pain points. Great place to change strategy— feeling quickly and feeling early.
Uber: entering India and other emerging market (more cash-based economy). had to make compromise on automation and increase operations by allowing cash-based payments. Nowhere else in the world were they doing this. but to optimize their mission statement which is to provide reliable transportation to everyone, they decided to compromise automation, which is very important to them, but the customer needs come first
Febreeze (non tech space): a bit of a flop— if you provide a solution to people which they don't really see a need for its not going to do very well. but they saw a lot of people using Febreeze technology right after they finish cleaning or right after someone smoked. So on the product side, they added a scent to the product just to give the users a sense of reward as soon as they used the spray. So marketing team updated their strategy and sales increased
Google Buzz: Short-lived product. Google’s first foray into social space. working on it for really long time. heavily dog-food'd— a lot of internal employees were using this for a while and nobody came up with any exceptions to it but were just tweaking it a little bit, improving the product here and there. launched product and it did really really badly. So badly that engineers were called back over the weekend to improve it and fix certain things. What was wrong with it was their entire social graph was based on Google contacts that people had. When you sign up, ALL your contacts from the past would get all these messages telling you to join. For some reason, their sample size of internal dog-fooders never brought this up. huge privacy concern for a lot of people. good example of how you should be getting user feedback and talking to your users and doing that all thru the product dev process but its very important to know what the sample sizes and what the type of people are that you're talking to as well. make sure they're a good representation of who your users actually are.
2nd part: WHEN
ANYTIME— ITS A NEVER-ENDING TASK
4 different stages you iterate over (1) discover & define (2) develop (3) launch (4) learn (what when wrong, what went right)
At any point in time, you’re never just in one place at a time. Features can be scattered in all different stages. Each type of feedback you would need would be very different depending on kinds of questions that you need to ask for that phase.
Discover & define:
What are our core customer segments?
What are their pain points?
What features would alleviate those pain points?
This is where you can start thinking about go ahead and cheaply solve for whether theres any interest in those customer segments (like doordash) before you involve engineering and other resources for dev. Time you can fail cheaply and fail quickly. very crucial part
Develop:
Does the MVP (minimum viable product) meet our customer (and business) goals?
What product refinements can be made pre-launch?
Figure out what those small improvements are which could be huge problems once you launch.
Launch:
Did we meet our goals?
Where our hypotheses correct?
Where did we fail and why?
Phase questions go from open-ended to specific. data goes from very qualitative to very quantitative (makes sense since you’re going from having this hazy nebulous idea to a very concrete product at the end).
HOW do we get answers to these questions and what are the different tools that you can use (not exhaustive)?
Discovery and Define phase:
Google consumer surveys, any tool that allows you to get open-ended answers. if you want quick answers to things
Mechanical Turk, ask people from around the world about what their preferences are about whether a certain idea that you have is actually going to be useful or not for them
Guerilla marketing- go and talk to people. instant feedback, can see the expressions on their face (very powerful)
INTERNALLY- good to talk to sales team at all points of time especially b2b companies (theyre the ones who talk to customers all the time). growth teams or operations teams for b2c companies are very useful to talk to
Develop:
User testing.
Guerilla— taking a prototype on your phone and going to people, and seeing how they react is extremely valuable (most old-school way of getting instant feedback but its the most personal you can get). also build empathy with customer
Lookback app— allows you to do user testing on phone where user could be in any part of the world but they use lookback and you can see where theyve been clicking and see the expressions on their faces (closest you can get to being there)
Internal dogfoooding- learn from Google Buzz.
Launch:
Intercom- its a little chat bubble on every single website these days. “hey x, z is ready to talk to you”. greate way of getting instant feedback from people about what they like/dislike
Amplitutde- if you have good analytical instrumentation within product, gives info about whos using app, when they use product. depends on how you have implemented analytics infrastructure but great way of getting feedback. simple to use.
Zendesk- way to build support infrastructure within application. dev FAQ page out of the box without involving engineers too much
Google BigQuery-sql editor
Talkdesk- build a call center within a call center within five minutes
Amazon redshift- sql editor
You cant think about what tools you want to use after launch. you should know about this and preemptively think about this. Build in this instrumentation while development process is taking place. if youre doing this after launch, then youve already lost the plot.