21–30 of 41 posts
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 contraria…
Earlier quoted context omitted.
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!”
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.
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.
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? -- the…
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 o…
I read Ken Kocienda's book about working on the original iPhone keyboard [1]. He says development revolved around demos: first to each other, then to senior leadership, then to Jobs.
2000s Apple tried to hire people with good taste, then constantly tested against that taste. It was all internal, but it was testing.
Earlier quoted context omitted.
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.
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…
I doubt there are too many people in tech making this mistake, but without numbers there’s a good chance you fall prey to people’s inaccurate perceptions or explanations for their own behavior.
On the other hand, without those first-hand accounts, it’s all too easy to tell a mistaken story about your numbers. In particular, your users’ sentiment towards their time spent in your app is a guess, unless they tell you.
I think timescale is another crucial dimension to evaluating time-in-app, and whether it’s a positive indicator for your business.
For instance, driving up engagement has doubtless been good for Facebook’s financials in the short- to medium-term. Arguably though, that relentless focus has led to the present political climate where they’re fighting off regulation. Whether that’s an existential threat is yet to be seen (one can only hope), but it certainly casts the metric in a different light.
As you say, it comes down to the fact that there is no silver bullet metric; there’s no substitute for thinking about and dissecting the data you collect.
Moral of the story is scratching your own itch makes you qualified to talk about the problem, it doesn't make you an expert on a good solution.
0: https://kitemaker.co, the super fast, hotkey-driven product management tool/issue tracker that has deep integrations to GitHub, Figma, Slack, etc.
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.
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...
One mistake I (and no doubt other founders) made was assuming you'd "get it right" because you were scratching your own itch. My cofounder and I started our company [0] literally based on the pain points we were feeling and still, when the first user tests on the first version of the product came around, users didn't get it. Or they didn't see the value. It was a tough lesson - we were building the thing we thought w…
That didn't work out so well.
It wasn't what they needed.
They didn't buy the product.
But we kept talking to those users and understanding what they thought they were getting and the problems they were hoping to solve. Those conversations gave us a better idea of what would work and helped build a realistic roadmap.
Executing on that roadmap has worked for us. We continue to evolve that roadmap based on customer demand - When somebody asks for something that's on our roadmap, we count their vote.. and generally prioritize work in order of demand.
So ya, talk to your users... it's not about what they ask you build, but what problems they're trying to solve.
0: https://www.enchant.com - shared inboxes, knowledge bases, live chat.