[HN Gopher] A founder's guide to understanding users
___________________________________________________________________
A founder's guide to understanding users
Author : mgadams3
Score : 82 points
Date : 2020-12-02 18:46 UTC (4 hours ago)
(HTM) web link (mgadams.com)
(TXT) w3m dump (mgadams.com)
| kungfukenny wrote:
| Solid post. Any advice for a founder on how to start engaging
| with users after a few years of _not_ doing that? Luckily we've
| had success despite our inability to get user feedback, but
| obviously we need to do better.
| kareemm wrote:
| If you're SaaS I'd start with sending automated emails to ask
| for feedback at key points in your customer journey. You might
| find this article I wrote to be helpful[1]. It covers those key
| points and also includes examples to make it easy!
|
| 1 - https://www.savio.io/customer-feedback/ask-for-user-
| feedback...
| mgadams3 wrote:
| We did concierge onboarding and set up shared slack channels
| with many of our early teams. This made it really easy and
| expected to ask for more feedback and to have users give it
| proactively.
|
| Community channels are key as you grow. Frankly this is an area
| where we've underinvested as we've been heads down
| building/shipping product and is going to be a huge area of
| focus for us in 2021. The job of the founder is to really to
| give people who love your product a venue to share their ideas,
| questions with other users. Customer advisory boards work well
| too.
| coderdd wrote:
| I like how the subtle repetition of using the word "gain"
| programs the mind to associate to grain.
| nathias wrote:
| "Your ideas are not nearly as important as your process -- and
| the best process starts with understanding what the customers you
| wish to serve already do to solve their problems today and even
| more importantly, understanding why."
|
| Ideas matter, if your ideas do not include a reflection of
| current ways people are solving problems you have bad ideas and
| would be better off thinking and researching before talking to
| anyone.
| mgadams3 wrote:
| For sure, ideas matter A LOT. But we over-index on product
| solution ideas by default.
|
| I think ideas that matter most for is for founders are the ones
| around a strong conviction on the market opportunity and then
| be flexible about the solution that is built to capture that
| opportunity.
|
| The latter is where I think process is more important than the
| product solution idea having seen my product solution ideas
| fail hundreds of times without changing my market vision ideas.
| gfodor wrote:
| Advice like this is fantastic, but I hate when it's positioned as
| the one-true-way to do product development.
|
| Consider some of the greatest inventions of all time: the
| printing press, the telephone, the airplane, the Internet, and
| the web. Considering the notion that they would have been
| conceived of this way is absurd, so clearly there's more than one
| way to make something people want.
|
| Mix in the fact that contrarians often disrupt things the most,
| and when you see a _process_ like this that itself has become
| considered the consensus approach, it seems like a high point of
| potential leverage to just try a different method, especially if
| that one has also been proven to work or is more in tune with
| your own talents, experience, and intuition.
| [deleted]
| asimpletune wrote:
| I don't see why those things couldn't have been invented by
| this process?
|
| The article specifically states that you focus on your
| potential customer's problems, not the solutions they want or
| would use. Ie, you're not asking if they want a better horse,
| but you are asking what sucks about the one they have today.
|
| From there better shoes, saddles, or even a car/plane can come
| out of that discussion.
| gfodor wrote:
| I don't think the kinds of 'problems' people may have
| articulated that these things solve would have been
| revelatory enough to argue they fit into this process. At
| best, the problems would have been so general like "I am
| uneducated about the world" or "it takes a long time to
| travel between places" that they are effectively immaterial
| when it comes to the process that led to these innovations.
|
| For example, if someone told you today "I don't like that I
| am going to die one day", would you be able to iterate your
| way via customer development to stop death? Would the fact
| that people don't want to die be incorporated in the
| understanding of the process that led to any solution that
| gets created? No. Some problems are either so obvious or so
| non-obvious that the spark of insight that leads to solutions
| is barely influenced by the articulation of the problem or
| lack thereof by those who are suffering under it, often
| completely oblivious of it.
| mgadams3 wrote:
| Thanks, I agree that the default path of "be like Steve Jobs"
| is a trap that I've fallen into enough times to realize that
| there are more ways to build where you don't have to have the
| insights up front.
|
| The key in my opinion is to be able to identify market
| opportunities and problems to solve, then be REALLY flexible
| about how you go about solving them b/c your first product
| solution ideas are very unlikely to work.
| gfodor wrote:
| I agree this is definitely a great way to solve problems,
| it's one of hill climbing basically, where the tactics and
| strategy really need to be carefully managed since it's very
| easy to get the gradient or step size wrong.
|
| Another way to see it is it's a form of de-risking an already
| risky endeavor. Anytime you reduce risk by adopting a
| methodology or formula that has known benefits, you're
| basically trading options (in the financial markets sense.)
| In this case, you're (probably) reducing downside risk, while
| increasing the odds of success, but at a cost of reducing the
| overall maximum upside, since your odds of creating a once-
| in-a-generation disruption goes down if you're using a hill
| climbing methodology to create wealth.
| jeffinpdx wrote:
| Sure, we've all known founders who've created products that were
| successful without talking to potential users, but it's very
| rare. What we've all encountered more often: founders who
| stubbornly don't talk to users as some sort of half-understood
| adherence to the biography of Steve Jobs. And then their product
| fails. If they had only tried a different way -- I don't know,
| talk to the people who might pay them? -- they could have avoided
| complete failure. It's not as glamorous as magically stumbling on
| a good idea, perhaps, and requires extra work, but it's often a
| more viable path for most of us.
| mmcdermott wrote:
| I think what gets overlooked about Jobs, even among his
| admirers, is that he did start with an audience. Particularly
| by the macOS X and iOS days, Jobs was fundamentally driving the
| product design towards what he wanted with the implicit idea
| being that if he liked it and used it, others would too.
|
| This has its own pitfalls, but he was fundamentally "talking to
| users", he had just narrowed his focus group to a user of one.
| He used his own products as far as we know as well.
|
| The thing is that most tech doesn't dogfood quite so easily.
| Most founders can't replicate that as they are generally
| selling outside of the consumer market that they can just adopt
| themselves.
|
| So, maybe cast another way, every product must have a target
| demographic and you need to interact with that demographic to
| get feedback on what you're building. Jobs just happened to
| have a shortcut that isn't generally applicable.
| Hendrixer wrote:
| Great read for any founder of a company from the early stages to
| beyond.
| mgadams3 wrote:
| Thanks Scott. I remember back to our convos in the Grain office
| from a year back that helped to inspire the structure of this
| post. Was cool to see you invest in it at Tipe and reap the
| rewards!
| kareemm wrote:
| Great read and bang-on (I'm running product on the fourth
| software business I've started - the first three were sold). But
| there's a missing piece to the puzzle though. The author talks
| about using data so that you don't fall victim to bias, but he
| doesn't talk about _how_ to do that.
|
| In my experience to ensure data-driven product decisions you need
| both a _system_ and _process_ to:
|
| 1. Collect feedback
|
| 2. Organize it to be useful
|
| 3. Analyze and prioritize customer problems
|
| 4. Use your feedback to validate problems and solutions directly
| with customers
|
| 5. Communicate status to your team
|
| 6. Close the loop with customers when you build their requests
|
| At the early stages you can do this with a spreadsheet or Trello
| board. Eventually you'll graduate to a tool or in-house solution.
|
| Here's a piece that dives into the details about how to build
| your own system to collect and organize feedback so you can
| eliminate bias and drive product decisions based on data:
|
| https://www.savio.io/blog/product-leaders-guide-customer-fee...
| mgadams3 wrote:
| Author here. Great feedback and completely agree with your
| comments.
|
| Taking a structure/organized approach to collecting, indexing,
| and sharing the qualitative data isn't something I covered here
| but absolutely essential to make sure that a research project
| scales. My experience has been that the first mile is where
| founders get the most lost.
| vmception wrote:
| The real question is how do you get data that customers are
| spending more time in your product because they are annoyed as
| hell
|
| Your A/B test just says "look, they spent more time, do it
| again, they _love_ that antipattern!"
| leobakerhytch wrote:
| That's what qualitative data is for. At the very least,
| talking to customers and reading their feedback. Preferably
| followed by organizing that data somehow, and using it to
| better understand the quantitative data you have.
|
| It's fair comment, though, that undifferentiated 'engagement'
| is rarely a good metric.
| kbenson wrote:
| Also, hopefully the people in charge are thinking closely
| about what time engaged _means_ , for that product. I
| imagine breaking user actions down to intent, if possible,
| would help quite a bit with that.
|
| For a product that is supposed to be simpler and save
| people time compared to the alternative, increasing time
| using the service might mean people like it and are getting
| more done so using it more... or it might just mean that
| it's getting harder to use. Then again, maybe they've
| graduated from doing simple things with it to complex
| things, and even though interactions take longer, they're
| still saving more time and effort overall compared to the
| alternative and are happy.
|
| I guess the bottom line is I think you have to slice and
| dice the data a lot of ways and think about what it
| actually means for your product to be using that data
| effectively.
___________________________________________________________________
(page generated 2020-12-02 23:00 UTC)