Building a product from scratch is a daunting challenge. When it comes to innovation, there are so many unknowns, so many questions.
You know you’ve got something, but the path to launching a new product can feel overwhelming. Don’t know where to start?
Here’s some simple and agile suggestions to follow that will help go from an idea to a finished product.
Make Sure Your Idea is Validated
A good idea is not a guess. It shouldn’t just sound catchy. Like “we’re going to make the Uber of this or that.” A good idea is a concept that is validated. That means you’ve done some objective verification of the notion. See my previous post for more on idea validation.
Start with the important stuff
Most development teams traditionally start with the login and the boarding experience. Often leading to a situation where the development teams are a half way through the timeline and haven’t built the core functionality.
The core functionality in modern hardware and software innovations will come with many dependencies. Make sure you start with making the core user experience and related API services. Starting at the core should expose lots of unforeseen complications. Better to know at the beginning than the end.
Define the work streams and a core team
Start small. Small pieces of work done by a small team. Try breaking down your product into lots of small parts organized in a logical order. Make each feature or element match a three-day build cycle.
Try starting and ending your weekly development sprints with customer feedback. Use the customer interaction for insights at the beginning of the week and validation by Friday. After every round of development and testing, reflect on the learnings and use those insights to inform the brief for the next round of development.
Minimum weekly sprints example:
- Monday: design and dev brief
- Wednesday: build
- Thursday: test and learn
- Friday: refine and test
Avoid building in parallel unless you have a lot of experience or you face a huge time constraint.
Start with a working prototype
Take your small team focussed on discrete core functionality and set the first release expectation as a prototype only. Said differently, a raw, barebones product. No login, no fancy graphics.
You can use this format to test with customers. No problem. Success starts with building from the center outwards. Test and learn the essential user experience you wish to create. For clear insights, your prototype should be tested with at least 20 customers.
Build a minimum viable product
Developing an MVP assumes that your prototype passed your user testing with flying colors. Users were genuinely wowed!
So now it’s time to connect with those tricky API services. The other important thing to start at this stage is real user interface design. This development and design done at this stage is at the heart of product creation. Lots of details. Lots of bugs.
It’s time to move user testing to a much larger scale. You want to see your MVP going into a public beta. This means a working version of core features, with complete front end design used in a public beta of 100-1,000 unaided users.
This should feed the design and development teams all the issues they need to solve before launch.
Launch your product, quietly
The biggest tip I can give you here is to do a soft launch. Put your product in the public in full distribution. But don’t shout about it.
Be it analog or digital, all new products need time to settle in. Hosting and browsers issues often need attention when the app is pushed live.
In the analog work you have issues with retail, distribution and all those real life conditions such as wind, light and noise.
I’d love to hear your comments and suggestions. Just email [email protected]
About the author
Mike is the Head of Innovation at QUALITANCE. He’s passionate about emerging technologies and experience design. Over his award-winning career, he’s worked on big innovation and marketing projects for Nike, Levi’s, Xbox, GE and many others.