3 ms·
Even before a beta, work with your prospective customers directly and closely. Determine what they really need and how you should really solve their problems be
by calinet6 12y ago
Even before a beta, work with your prospective customers directly and closely. Determine what they really need and how you should really solve their problems before even presenting a product. If you don't do that before building a product, chances are you've built the wrong one, and a beta will only give you one or two degrees of course corrective ability from there.
- beat 12y agoThanks. I feel really good about the "solve their problem" part. The problem I'm trying to solve is engineers working on large, complex software systems who can't fix things because they don't have access to the information needed to fix it - it might be locked away in silos, or in opaque enterprise tools, or simply lost (you applied that patch - do you know what it looked like before you applied it?). I've worked in that field for 20+ years, and talked to literally hundreds of engineers about it. When I start hearing phrases like "holy grail", I'm pretty sure I'm solving a real problem. :) The trick, though, is the subtleties. The transition from "this is a great idea" to "eating my own dogfood" taught me tremendous things about the product. The transition to beta will teach me a lot more. What I want to do is make sure the data is as useful, well-structured, and accessible as possible. I don't think I can do that without real-world testing, but what testing approach is best? This is where Slack excels. Lots of companies make IM clients. Why is Slack so far-and-away better? What did they do so right?