3 ms·
Ha, sounds like a good part 2 to me! :) As you pointed out, you did allude to it in the article. I was just trying to add a bit more based on first hand experi
by rpeden 10y ago
Ha, sounds like a good part 2 to me! :)
As you pointed out, you did allude to it in the article. I was just trying to add a bit more based on first hand experience with software customers.
And hey, sometimes customers will just flat out tell you that they need a feature that is blindingly obvious to them, but didn't occur to your product development team. It's nice when it is that easy.
So I agree that the knowing how to interpret what your customers say is and important part of being able to act on what they share with you. That certainly doesn't diminish the importance of anything you wrote, though. Without engaging with customers and properly listening to them, there wouldn't be any information to interpret.
- davidmchris 10y agoIt's great feedback. Here's what Alex (atopiler) Slacked me yesterday after he read the article in draft "One thing that I felt didn’t really come through fully was some of the true essence of cust-dev calls. This is the product snob in me talking, but it felt a bit like we're listening to what our customers wish for, and we build what they tell us to build. When it comes down to it though, what the calls really reveal, and what we’re really trying to understand more deeply than anything else is what are biggest problems and frustrations they’re dealing with on a day-to-day basis? Why are these things frustrating? Why do they put themselves through that frustration? And what would it enable them to do if those problems didn’t exist?" And that became that middle section. Thanks to all of these comments I'm seeing the light of what he was really getting at there and I've salted the headline and some of the earlier passages to set that up a little better. p.s. this is my intro to HackerNews - you guys are awesome.
- atopiler 10y agoAbsolutely - huge thanks for reading and for the thoughtful replies!