So you have an idea, you spent sleepless nights thinking through it, and convinced that it is time to start the development process for your new product.
You know you need wireframes, design mockups, and a minimum set of features prioritized before you can pass it to the development team to build the product.
But that’s just scratching the surface area.
Because you don’t just want to build a product, do you? You want users to find value, start paying for it, and love your product with every fibre of their being.
Your new product development process should be a conscious decision birthed by the problems your customers have.
With the odds stacked against you, how can you ensure your new product development has a process that doesn’t make you just another “me too” product?
The new product development process in 4 Steps
1. Ideation and Research
Every great product was once just an idea, an itch, a frustration the founder had with the existing status quo.
Whether you are building a product for your new startup or looking to add a new product to an existing lineup, this is the stage where you will have to tread carefully. Because an idea, when it first hits you is at its most vulnerable form. Even the smallest form of critique or negative comment can fizzle it out of existence.
Share your new product idea prematurely to the wrong person and you risk killing a billion-dollar idea. Share it too late and you risk spending too much time on something that wasn’t worth investing in at all.
So, how do you validate your new product idea?
If you are sitting in a large company, you probably already have all the data and research you need to validate your new product idea. But what if you are a small startup with a limited resource?
Your first instinct might be to go and ask your friends, peers, or maybe even strike up a conversation at your local startup event if you’re the social type. But before you even start asking your friends for feedback on your new idea, you need to ask yourself:
- What market are you developing your new product?
- Who is your competitor in the market?
- What is something that you provide either as a standalone feature or as a capability that your competitor doesn’t?
- How does this benefit help your customers?
- Why your customers need this benefit?
Once you have answers to all the above questions, it is time to talk to a set of prospective customers to see if they resonate with the problem you are solving.
Even if you don’t get it right on the first attempt, by having more conversations with people on how they currently work and understanding their current pain points, you will be able to articulate better.
"We needed to stop building what we thought the market wanted and get back to basics. Instead of writing code, we went out and talked to customers. We spoke with people who used our largest competitor"
~ Hiten Shah, Founder UseFYI
The goal, with every conversation you have with your users, is to inch closer to an accurate description of who will want your new product, what their current workflow is, and what their pain points are.
2. Strategic Planning
Most teams have a plan as a roadmap either on a paper, notebook or in a project management tool.
But there’s a lot that goes before a feature gets added into the roadmap.
Adding a bunch of features to a roadmap is the easy part. But the hard part is making sure the right set of features are added and prioritizing which ones to build first.
After all, there is always more to build than there are people to build them.
Depending on what market you are building your new product for, the number of features you need to build will vary. For example, if you are building a CRM tool, there are plenty of basic functionalities you will have to build to call yourself a CRM tool, followed by the functionality that differentiates you from the competition.
The key to a great roadmap is to have a balance between features that you need right now and the features you want in the future.
Because if you don’t build the obvious features that you need right now, your customers will leave due to lack of features. And if you aren’t building features for the medium or the long term, you risk losing your customers due to lack of differentiation.
As hard as it is to nail differentiators, it doesn’t have to be a separate feature by itself. Differentiators can be baked into the experience, say, by making the product easier and faster to use.
Prioritize your features with Zepel's drag-and-drop cards, assign owners for who is responsible for ensuring the feature meets the quality standards, and set deadline to ensure you ship on time.
![Prioritize features with Zepel]https://zepel.io/blog/content/images/2019/07/Simple-project-management-tool.png)
3. Development and Testing
Before you even bring in your team, it is important to know what the feature should do.
Even if there are certain aspects of your feature that you might not to build due to time constraints, simply jotting everything down will help conceptualize your feature and give you a good idea of what to build and what you don’t have to.
Product development is a non-linear process with plenty of back-and-forths happening across and within teams.
You know you need to bring in your designer, build wireframes, and pass the design for your team to build it. Even after your development team has built it, you know there will be iterations on the feature that will take the feature back to the design team. Even after a feature is passed to the QA team, it still comes back to the development team for bugs that need to get fixed.
Yet most teams mistake this step in the process by assuming product development to be linear. This non-linear aspect to product development process makes it harder to collaborate, predict, and become efficient.
Knowing which tasks need to get done and which ones are still in the burner is a step-up from completely sitting in the dark. But when you are running behind and need to course-correct to ship a useable feature on time, knowing what’s “not done yet” is hardly sufficient.
You need to know the progress of the feature from the perspective of every team involved.
After all, knowing that Martin hasn’t shipped out that feature yet isn’t half as useful as realizing that it’s functionality complete and currently going through final touches by the front-end team and is waiting for an update from the design team.
With an initial version of your product ready, you should now be able to show your product to a small group of target audience and ask for feedback.
Talking about your product in closed groups such as on Facebook Groups, Slack communities, Reddit, and BetaList is a great way to get a quick influx of users to use your product and feedback.
4. Launch and Commercialization
A well-planned launch can be powerful. It lets you get in front of an audience, helps get your product adopted, and ultimately bring customers.
With all the answers for the questions in the first step and feedback from your early users, you should now have enough information to position yourself that resonates with your target audience and attract them during your product launch.
But your work isn't nearly half done once you've launched.
Think about the time you used a software and ran into an issue… You found it online, enjoyed using it because it solved a pain point you had. But there was that one pesky issue that kept getting in your way. You report it to the team, but after a few months, it’s still there nagging and disrupting your workflow.
What do you do?
You still need to keep track of your users, see how they are using, measure the success of your features, get feedback, and tie it all back into the product.
All customer feedback comes with multiple motivations, each of which could vary from feature requests to enhancements or more serious issues that disrupt their workflow. The key is to be able to capture all feedback into your project management tool, so you can prioritize them and keep your users happy.
By using an in-app chat tool or adding a feedback button within your app, you can quickly gather and prioritize user feedback. This can serve as a good fodder to keep engaged users happy and likely make them want to start paying.
The difference between good products and great products can be seen at how fast they build, gather feedback from their users after launch, and tie it back into the product.
After all, you wouldn’t want to lose one of your engaged and paying users because you didn’t incorporate their feedback.
Your new product development process is never "done" at the end of the fourth step.
It is a continuous loop that goes through multiple iterations that will help you not just ship features on time, but also build bug-free, useful features that gets adopted.
Because when you build products that is glitch-free, useful, and has user feedback baked into it, users don't just back due to notifications and alerts. They come back to your product because they want to.
Top comments (0)