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 we wanted and others didn't want it. But we persevered, pivoted a little here, rewrote a lot there, and ended up with something that users not only liked a lot more, but also worked better for us too.<p>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.<p>0: <a href="https://kitemaker.co" rel="nofollow">https://kitemaker.co</a>, the super fast, hotkey-driven product management tool/issue tracker that has deep integrations to GitHub, Figma, Slack, etc.
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 <i>how</i> to do that.<p>In my experience to ensure data-driven product decisions you need both a <i>system</i> and <i>process</i> to:<p>1. Collect feedback<p>2. Organize it to be useful<p>3. Analyze and prioritize customer problems<p>4. Use your feedback to validate problems and solutions directly with customers<p>5. Communicate status to your team<p>6. Close the loop with customers when you build their requests<p>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.<p>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:<p><a href="https://www.savio.io/blog/product-leaders-guide-customer-feedback/#what-does-a-good-feedback-system-look-like" rel="nofollow">https://www.savio.io/blog/product-leaders-guide-customer-fee...</a>
We went all-in on Enchant [0] with a set of screen mockups and potential users telling us that it was exactly what they needed.<p>That didn't work out so well.<p>It wasn't what they needed.<p>They didn't buy the product.<p>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.<p>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.<p>So ya, talk to your users... it's not about what they ask you build, but what problems they're trying to solve.<p>0: <a href="https://www.enchant.com" rel="nofollow">https://www.enchant.com</a> - shared inboxes, knowledge bases, live chat.
Advice like this is fantastic, but I hate when it's positioned as the one-true-way to do product development.<p>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.<p>Mix in the fact that contrarians often disrupt things the most, and when you see a <i>process</i> 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.
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.
> I had listened to what they said — exactly as they said it, but I did not realize until much later that I failed to actually understand what they meant.<p>Two things come to mind:<p>1) Wants are not needs. To pun Ford a bit, "I want a bigger, faster more reliable horse to get to work. Something safer for my family" is what the clearly stated want is. Remove horse and you're at root need. The Need. Too often, The Need is never distilled from the want.<p>2) In Covey's classic book "7 Habits of Highly Effective People" he says something along the lines of: Seek first to understand, then be understood.<p>Yes, listen with intent. But before you write a single line of code, draw - yes, free-hand - a prototype of (what you think) you heard and share it with the other person - the user, the customer, even a colleague.<p>Never assume. Never assume a want is The Need. Never assume you understand until you've vetted that understanding.
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.
This sounds very similar to what Design Thinking suggests. Connect with your (potential) customers to get their habits and preferences so you've more ideas and then prototype them through mockups or small models and once you've the feedback from the customers, decide to either go ahead with the version 2, pivot it, or shelf it.<p>Design thinking talks about being empathetic to your users/customers. Which also sounds like the essence of this post.<p>Thanks for writing it.
"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."<p>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.