How do you go about launching a new web product? It's a difficult call to make; you want to get your new ecommerce website out there, but you don't want to release it if it's not quite ready yet, but what if someone else appears with something similar while you're busy polishing? It's all too confusing, so we went to our panel of experts for some tips.
Rachel Andrew
You should launch your product as soon as it solves a problem for your ideal customer in a way they are happy to pay you money for. Your MVP doesn't sell anyone short as long as it does what it is advertised to do. From that point you can add features, but those additions will be based on real customer feedback and not just things you think people will need. As a bonus your early customers will enjoy seeing new features being added, and appreciate their needs being taken into account.
Rachel Andrew is managing director at edgeofmyseat.com
Jeff Gothelf
We define a vision for the product - i.e., what is the problem that we're trying to solve and how will we define success. From there we iterate from initial concepts towards a final state basing our decisions on rapid feedback cycles with our target audience, our design aesthetic and our brand values. The process of rapid iteration based on evidence from the market reduces the risk of the project. Each cycle of feedback nudges the project execution in a direction that is more likely to succeed.
Focus is the key. Determine the core problem to solve and the absolute minimum feature set needed to solve it. Make sure customers love it. Then scale it to find a repeatable business model before adding new features.
Jeff Gothelf is an author, teacher, designer and speaker at Neo, NYC
Jonathan Smiley
Validating concepts is critical, but the idea of the minimum viable product leaves too much opportunity on the table. Don't strive for minimalism, strive for a great experience, and make sure you explore the problem enough that what you build as your first iteration is something that really resonates. It's still just your first version – the next will be even better.
Jonathan Smiley is partner at ZURB
Ross Bruniges
I think you should release as early as you can; and that's variable of course due to the nature of your business. It's only once a feature is live that you'll know it's real value to your users so get it in front of them as soon as possible and from there work on the finer details based on the real world feedback opposed to a designer of developers ideas - which may be based on best practise but may end up being totally wrong and lead to effort being put into the areas that REALLY don't need it.
Ross Bruniges is responsive developer at hotels.com
Alex Watson
A lot of people have this idea that a roadmap is a single document, but it's best to think of it as a collection of documents, data points and discussions that cohere into a solid strategy and an idea of how you will execute that.
You should be able to communicate a version of this roadmap in a couple of sentences, a ten minute slide deck or a series of detailed user stories - and many points in between.
It depends on who is asking, because it's critically important to understand that a roadmap serves many different functions within a company. What senior stakeholders, such as the members of the board need, is very different from what your lead developer or QA needs. The important thing is that you can speak coherently and give answers to a wide range of people that might differ in detail but shed light on the same problem you're trying to solve. So a senior stakeholder might want to know what you're doing to "engage with social," and your designer might want to know "what happens when a user presses the Twitter button," and your developer might want to know which service or API to call to post a Tweet - these are all aspects of the same question and should be addressed by the same part of the roadmap.
As you go from a high level vision to something more defined and detailed, you should be prepared to adapt and evolve based on data, the technical landscape and user input. There's a great diagram in The Lean Startup where Eric Ries explains that Vision shouldn't really ever waver, Strategy should be changed rarely but Tactics ought to evolve constantly which I think is spot on. I want to make engaging products, but if we find that users' vision of that is different to what we initially thought, it's pretty clear we ought to be flexible about our vision.
No-one gets it right first time, because when it comes to digital there's no "right" answer. Digital product developers are not miners, searching for a seam of gold, where the world is divided into worthless rock and solid gold. Good products have a way of making users coalesce around them and it's often a blend of proposition, marketing and evolution.
Alex Watson is head of product for mobile at The Telegraph
Des Traynor
Most product roadmaps stop at 'Ship version 1.0', and at that point the product team is spent. Out of energy, out of budget, out of time.
Unfortunately that's the first point where you can get real insight from real feedback. It's the first time you'll confidently know what features you need to build and in what order.
So whatever your roadmap is, make sure you have lots time, energy, and budget available after you ship, that's the where the real work starts.
Des Traynor is co-founder and VP customer success at Intercom
Amy Hoy
This sticky dilemma solves itself when you reframe the question: Don't start with an idea, start with a very specific customer pain. Don't keep asking yourself, "Is the product ready?" - ask, "Does it help customers kill that pain?" It's easy to focus on product; product's what we do. But customers don't want a drill, they want a hole; they don't want a hole, they want to securely hang the mobile over their new baby's crib. Relentless focus on the customer - and that customer's results - is the best way to make something people will want, use, and buy, even if it's 'incomplete'.
Amy Hoy is whipcracker at Freckle Time Tracking and 30x500
