5-Step New Product Development Process You Can Execute in the Next 30 Days

5-Step New Product Development Process You Can Execute in the Next 30 Days

There are few things more exciting than developing a new product (and launching it). After toiling for ages behind the scenes, throwing back the curtains and showing off your hard work to the world is an incredible feeling. Until it’s not.

According to a review of studies dating back to 1977, 40% of new products fail within their first year.

Even if you think that number’s inflated, it’s still a terrifying prospect. Imagine spending months or even years on new product development, creating something you think your users will love, only to leave its success up to a coin toss.

New product development is the lifeblood of every company. Yet, if done improperly, it can be one of the riskiest and costliest endeavours you’ll go through.

But it doesn’t have to be this way.

There’s a reason companies like Apple and Google consistently put out successful products: They’ve spent the time testing and refining a new product development process that minimizes risk and maximizes answering any uncertainties before going to market.

In this guide, I’m going to run you through a 5-step new product development process you can use to define, create, and launch a new product in 30 days or less.

Need help developing new products? Here at Sprintwell, we help purpose-driven teams design business solutions, products, and new services their customers will love. Get in touch!

The reality check: Why so many new products fail

Before we get into the process, let’s talk about that big, scary number one more time. Yes, nearly half of new products fail in their first year. But it’s important to remember that number can be misleading.

Sure, sometimes even seemingly great products will fail. But what’s more likely to put your company in that statistic is missing a major step in your new product development process. So before we get into the process itself, here are a few red flags you should always consider when building anything new:

  • Not understanding your market or target audience enough: The success of any new product, service, or solution comes down to just one thing: solving a real problem. If you don’t take the time to deeply understand your customers and the market it’s all too easy to build something no one actually needs.
  • Customer don’t really understand what you’re selling: Being innovative is important. But developing products that are too beyond their time is a recipe for disaster. This is classic business blunder where you try to offer something different to differentiate yourself from customers but make something so different than no one wants it.
  • Marketing and reality don’t match up: If your product doesn’t live up to the promises you’ve made in your marketing you’re not only going to end up with poor sales, but angry customers. More than ever, user reviews matter. And you have to be careful to not set the bar too high if your new product doesn’t deliver.
  • Poor pricing strategy: Pricing is one of those things that feels like it should be natural, but rarely is. It’s always worth the effort to find out what customers are willing to pay and come up with a solid pricing strategy.
  • A weak product launch: Your new product won’t succeed if no one knows about it. Don’t fall into the trap of thinking that just because your product is great people will find it on their own.  

Yes, new product development is risky. But it’s also one of your biggest opportunities. If you understand what you’re up against and are ready to go through with it, here’s exactly how to proceed.

The ultimate 5-step new product development process

At Sprintwell, we’re huge fans of shipping new products quickly.

While we know great work often takes time, in a lot of cases, you can design, prototype, and test new products in a matter of weeks, if not days.

This 5-step process will take you all the way from in-depth user research, to designing and testing prototypes with a design sprint, to building your MVP, getting final validation from your users, and finally launching your product to market. All in 30 days or less.

Working at this pace is equal parts exciting and anxious. Find out how Sprintwell can help you keep your new product development on track.

Step 1: Understand the problem you want to solve and prioritize the best options

Every great product starts with a problem. You want your users to feel like you built something just for them. And the only way to do that is to know them intimately.

The problem is that in our modern workplace with its emphasis on speed, it’s all too easy to jump straight into solution-mode without taking the time to check whether you really understand the problem at hand. Yes, you want to develop and launch a new product quickly. But all the work you do building something new will be pointless if it isn’t solving the right problem.

This is why the first step in new product development is research. Through a series of structured experiments, interviews, and investigations, you’ll be able to find high-value problems to solve, validate your idea, and prioritize the path you want to take.

Find customer problems to solve

There’s nothing worse for any company than solving the wrong problem. That’s why the ultimate goal of the research phase isn’t to find a great solution, but a significant problem.

To start, look at your current offering, the market, and your users and ask some tough questions, such as:

  1. What needs and motivations do people have?
  2. How do people evaluate and adopt products?
  3. Do people understand your product’s value proposition?
  4. Which messages are most effective at explaining your product?
  5. Do people know how to use your product?
  6. Why do people stop using your product?
  7. Why don’t people adopt new features when you launch them?

When doing problem diagnosis like this, it’s important to think about how you’re framing your thoughts. People have a natural tendency to get fixated on our own ideas (psychologists call this the confirmation bias). So make sure to get lots of outside opinions (which you’ll do next), as well as challenge yourself to reframe ideas.

One great way is to try a lateral thinking exercise, such as making a list of things that are impossible about your idea and then trying to disprove them, or choosing random words from the dictionary as a lens to approach your problem.

Whenever you have an idea for a product or feature that you think meets your criteria, build a simple prototype or mock-up of it. It’s so much easier to test and validate ideas with something people can see and try than just a description.  

Run a research sprint to validate your ideas

Once you’ve got a few solid ideas and mockups in the works, it’s time to quickly validate them with real people. The best (and fastest) way to do this is with a research sprint.

Designed by the team at GV (who also created the design sprint method we’ll get into), a research sprint is a four-day structured process that helps you maximize learning from actual users so you know you’re starting your new product development on the right foot.

There are five essential components of a good research sprint:

  • A set of questions and assumptions: Here’s where you bring together all of your great ideas you came up with and the concerns you have. Everyone on your team should agree beforehand on the questions and assumptions you plan to test.
  • A group of specifically recruited and qualified users: Talking to real customers is one of the most important things you can do during the research phase. You need to be careful to recruit people based on your specific goals. That means existing customers, prospective/ideal customers, or representative people.
  • A realistic prototype to test: You’ll get so much more insight if your users have a basic prototype to test with. We’ve written in-depth about how to make prototypes using design sprints in the past (and we’ll go into it here in the next section), but you can also use a current product or even a competitor’s product to test your assumptions.   
  • A solid script for 1-on-1 interviews: Communication is 55% body language and 38% tone of voice, which means you’ll always learn more from seeing someone interact with your prototype than just read their thoughts. During the research phase, you’ll be running five interviews with real users and want to make sure you take the time to properly prep and get the most out of your time with them.
  • Real-time summary of your findings: Research often gets bogged down with analysis. Make sure your entire team can watch the interviews happen in real time and record their observations.

The actual research sprint process is pretty simple.

On Day One, you’ll pick a day for your interviews (this should be at least three business days from now) and start recruiting and screening potential interviewees. It’s important to make sure you’re talking to the right people. For example, if you’re trying to break into a new market, it makes sense to interview people in that demographic. To find these people, define your criteria and then create a short screener interview people can fill out. You can post the job wherever it makes sense, like Craigslist or other job boards.

On Day Two, you’ll select the people you want to interview, call them to verify they’re the right people, and then follow up with an email giving them the date and time of the interview. Next, you should start creating your interview guide. This is a run-down of what’s going to happen when your participants come in and should include an introduction, context questions, tasks, follow-up questions, and a debrief. You should finish the interview and context questions today.

On Day Three, you’ll finish your prototype and map out how the interviewees will interact with it. What features do you want to test with them? When writing the task portion of your interview, it’s important to not put your own bias into the questions. Avoid saying words that appear in the UI or on the product itself (like “Help” or “My Profile”). Instead, ask open-ended questions and follow-up to dig deeper.

On Day Four, you’ll set up your testing space, making sure the rest of your team can watch the interviews remotely, and then run the five, 60-minute interviews you’ve booked. Your main job is to highlight the patterns you see and collect ideas for other possible solutions to the problem. At the end of the day, you should have a document with all your observations and know what your next step is going to be.

Prioritize your best options

There’s a good chance that your research sprint will give you a ton of great ideas you’ll want to continue to refine and test. But while having too many good ideas isn’t the worst problem you can have, the last thing you want is to fall under choice paralysis.

Chris Guillebeau outlines a simple, practical tool for starting this process of logical idea prioritization very simply in his classic book, The $100 Startup.

It’s called the Decision-Making Matrix. Here’s how it works:

  1. List your ideas and score each one on a 1 to 5 scale based on a few categories (Effort, Profitability, Vision, and Impact)
  2. Sum the total scores and sort from highest to lowest
  3. Take action on the highest scoring idea

And at the end of this process, you’ll be left with a ranked and prioritized list of which ideas, strategies or features you should pursue—built on the principle foundation of real anticipated impact within your business.

Another useful way to prioritize features and ideas is to follow former Wealthfront CEO Adam Nash’s advice and break them out into three buckets:

  1. Metric Movers: These are features or products designed to move business metrics (like growth, engagement, revenue, etc…) and align with your overall strategy.
  2. Customer Requests: These are features or products your customers are actively requesting.
  3. Customer Delight: These are features or products your customers haven’t explicitly requested, but that you know (or think!) they’ll love.

Once the features or product ideas are in these buckets, you can have an honest conversation about them. Are you more drawn to a product idea because your customers want it? Because your company wants to move metrics? Or just to be cool?

Your new product will most likely fall into multiple buckets. But if you see one area lacking, it’s a good sign that you’re missing out on some key research.

Once you’re done, write a product brief

At this point, you should have a pretty good idea of what your new product should look like. You might not know exactly what it is yet (we’ll get into that next), but you should be clear about the problems you’re solving and why you’re solving them.

To make this ultra clear, the final step of the research phase is to write a short brief around your problem and solution. And I mean short. Michelle Fitzpatrick, senior product manager at Intercom, says they keep their briefs to 250 words, while Sebastien Phlix, product manager at Typeform, says his brief will run to a maximum 2–3 pages.

Your brief should clearly articulate a few key points:

  • What problem are you solving and why?
  • Who is your ideal customer and why will they want this product? (i.e. what’s the problem with the existing solution?)
  • How will you measure success?
  • What is the scope of the product?
  • How will this new product contribute to your strategic goals?  

This is a powerful document for your entire team and should be accessible to everyone—and don’t forget that you can utilize a collaborative project management tool to further streamline this process.

Most importantly though, is to use plain English (no technical jargon or codenames) and write your brief as if you were describing the problem to a colleague face to face.

Step 2: Run a Design Sprint (and repeat as necessary)

Great product development is all about continually refining and improving your product idea before committing time and resources to it. And so while you should have a good idea of what you want to make at this point, you’ll want to test that idea or problem more thoroughly before running with it.

Here’s where it pays dividends to run a design sprint (or two/three/four!)

We’ve already written an in-depth guide to how to run a design sprint. But the basic idea is that a design sprint is a structured, five-day (or less) process for quickly designing, prototyping, and testing new products and features.

You’ll probably see some similarities between the design sprint process and the research sprint we covered in step one. Yet while our research sprint was meant to help define the problem and assumption we were making, the design sprint will help you validate that the path you’re taking is the right one and that customers understand not just the problem, but how your solution works.

You can also use design sprints to test specific features in a new product or try out variations on a user flow in a short timeframe.

Here’s a quick rundown of the five days of a design sprint:

  • Day 1: Set a long-term goal for your product or solution and then map out the challenge of getting from where you are now to that end goal with a simple flowchart of 5–15 steps. Next, bring in some experts to help give you added insight. While they’re talking, write down every problem or solution that comes to mind starting with the statement “How might we…” At the end of the day, vote on which problem to tackle during the sprint.  
  • Day 2: Take some time to talk about the solutions currently out there and then spend the afternoon sketching out solutions, product ideas, and user flows.
  • Day 3: Go over the sketches together and decide on what solution to prototype. You can pick multiple ones and test them against each other if you want. Then, draw a storyboard, or frame-by-frame plan of how you’ll build your prototype, making sure to fill in any missing pieces.
  • Day 4: Divide the storyboard up into individual jobs and start building. Your prototype should be high-fidelity enough that users feel like they’re using a real solution, so use tools like Keynote, PowerPoint, InVision or Marvel.
  • Day 5: Test your prototype with five real users, following the same interview strategy as your research sprint.

Note: Here at Sprintwell, we combine Day 1 and Day 2 into a single day when we facilitate design sprints for the teams we’ve worked with at companies like LinkedIn, SoundHound, and Indigo.

Want help getting the most out of your design sprint? Well, that’s exactly what I do here at Sprintwell. We have years of experience facilitating design sprints at companies like LinkedIn, Medallia, SoundHound, Springs Global, and Resolve, which is led by Dr. Tom Frieden – former Director of the Centers for Disease Control and Prevention. We also teach and mentor at the Stanford d.school, General Assembly, and 500 Startups.

It’s OK if your prototype fails at the end of your sprint

At the end of your design sprint, it’s not uncommon for the prototype to fail (meaning the users you interviewed couldn’t use it or said it wasn’t what they would want). This might be a scary prospect, but let’s think about the alternative for a minute.

A design sprint is just five days long. In that time, you might come up with a perfect prototype and be able to start building it with the rest of your team. Or, you build, test, and rule out one idea you thought was good. Both of these are fantastic results.

Knowing what not to build is as important as knowing what to build. As design sprint creator Jake Knapp explains:

“Even if you’re wrong the first time, the sprint process will help you light up your future path.”

Even better, is that if your first prototype fails, you’re already well on your way to building another one you can test with users. Thanks to the work you did during your research sprint and the first few days of your design sprint, a second or third sprint can be done in just 2–3 days each.

Step 3: Develop an MVP from your sprint results

With your design sprint done and the results saying you’re on the right path it’s time to start building. You’re probably starting to notice a pattern here where we build as simple a version of our product as possible and then test it with real users to get feedback. That’s no accident. Each step of this new product development process adds to the fidelity and functionality of your product and lets you test it with a larger group of users.

At this point, you’ve already built, tested, and validated your problem and potential solutions. Now, it’s time to hand over what you have to your development team to create an MVP (Minimum Viable Product).

If you’re confused by the difference between your design sprint prototype and an MVP, let’s use a simple analogy.

Let’s say your ultimate goal is to open a new restaurant. The research phase is where you ask people what kind of food they want to eat, start looking for recipes, and take a cooking class to learn how to prepare ingredients. The design sprint is where you use all this knowledge to come up with and test different recipes with friends and family. Finally, your MVP is when you make your dishes and soft open your restaurant.

In other words, the MVP is a more polished product that you will test with a wider group of users. This doesn’t mean it’s your final product. But rather the simplest form of your product that will allow you to test features and flows with users, get feedback on, and iterate.

How you go from prototype to MVP will depend on your product, team, and process. And while it’s impossible to list exactly how you specifically will run this process, there are a few best practices you should follow.

  • Don’t just throw your design sprint in the trash: It’s exciting to build something new. But the learnings you got from your design sprint are invaluable to your development team (who probably weren’t all part of it). Follow up on the results of your design sprint to test out the remaining customer journeys, features, and insights and share what you’ve learned with the entire team.
  • Stay Agile and move quickly: Create a detailed plan of who, when, and how the new product will be built. We’re huge fans of the Agile approach of continuous development so our suggestions would be to break your tasks up into a product backlog and use sprints to work through them quickly.
  • Teamwork makes the dream work: Yes, it’s cliche. But if you don’t communicate with everyone, including key stakeholders, during the MVP development process, you run the risk of not getting buy-in when it’s time to launch. Bring them in early. Keep them updated. And get everyone excited about the work you’re doing.  
  • Always create something usable: An MVP can’t just be a collection of features. It always needs to solve a problem (even if it does so in a basic way). For example, let’s say your problem is to get from one place to another. Your MVP would be a skateboard, not a car frame with wheels and a radio. One is useable, shippable, and could be bought by consumers. The other can’t.
  • Be careful when deciding the scope of features to include: Deciding the scope of features in an MVP can be tricky, which is why you should always ask for feedback early on and refer back to your problem throughout the process. A great example is the Tesla Roadster. Not only was it a fantastic, company defining product. But it also acted as an MVP for the problem they were trying to solve: To act as a catalyst to accelerate the day of electric vehicles.

Step 4: Test with more real users

Before you move on, let’s take a second to look at how far you’ve come. In just a few short weeks, you’ve gone from vague, ambiguous idea to polished MVP. Now, it’s time to take your budding new product out of the nest and see if it can fly.

User testing with your MVP is different than with your earlier prototypes. Rather than limiting it to five in-depth interviews, you’re going to open up your new product to a larger group of current and new users to see how they respond. Again, we’re following our pattern of continuously building, testing, and iterating until you have the best product possible.

Like most of this process, there’s no real constrained “testing” phase. But rather, you should be continually introducing new features, flows, and ideas as you iterate and build your MVP.

How you test your MVP will depend on what you’re building. But again, here are some best practices to follow

If you’re building an entirely new product: Beta test

No matter how much research and early testing you’ve done along the way, some issues slip through the cracks. And the last thing you want with your new product is a trial by public. Beta testing is when you release your product to a small group of real users and get them to give you feedback on usability, bugs, performance, and feature requests.

Beta testing requires a clear strategy and plan to be successful. That means defining the goals, questions you want answered, overall strategy, and deadlines. You might also want to have your beta testers sign an agreement (like an NDA) to keep your idea safe before launch.

During the beta test, look for patterns. Where are people having issues? What do they love (or hate)? How often do they use your product over the testing period? Are there features multiple people have asked for?

There are tons of tools that can help you run these beta tests and capture user feedback, such as:

All this information is invaluable and will help you make sure that when you do launch, it’s with the best possible new product.

If you’re releasing new or updated features: A/B test

People are resistant to change. If you’re updating a current product with new features, you don’t want to just release it without making sure that the change is going to be positive.

This is where A/B tests come into play. A/B tests are simple ways to expose a small, representative group of your users to a new feature to measure the results against other options (or the original design). This way you can see which ones perform best.

However, A/B tests shouldn’t be entirely metrics-driven (i.e. winner takes all). But rather, they should be metrics-informed, meaning they help aid your product development strategy instead of driving it.

Again, there are lots of tools that can help you run A/B tests, like:

Lastly, don’t forget to A/B test removing features as well, as small changes can sometimes have large, unintended consequences.  

Step 5: Do any final iterations and launch!

Remember our restaurant analogy from before? Well, at this point it’s time to make any final tweaks to the menu and open for business.

With your MVP built and user feedback gathered, you can make any final iterations to your new product and then go into launch mode. It can feel strange to put something out in the world that has been kept in secret for so long. But you should feel confident knowing you’ve gone through multiple rounds of prototyping and testing. At this point, your new product isn’t just your idea. It’s the culmination of feedback from experts, teammates, and real users.

Running through a full new product launch would be a post in itself. However, there are a few strategies that will help ensure your success:

  • Create a go-to-market strategy doc: There are always a ton of moving parts during a new product launch, which is why it’s important to keep everything organized. Create a go-to-market doc that outlines your strategy, deliverables, goals, and the tasks and dependencies that will get you there.
  • Get sales and customer support on board: Launching a new product is a company wide effort. Before you set a date, make sure your sales team has all the assets and training they need to sell it and your customer support knows to potentially expect a influx of customers and questions.
  • Use your community: Your current users are a fantastic tool for spreading the news of your new product. Make them a part of your launch through emails and events.
  • Don’t forget the power of story: Every great product has a story behind it, and yours should be no different. Explain the reasoning behind why you made what you did, the people you spoke with, the issues they brought up. Use the language of the people you tested your earlier versions with to connect with your ideal customer.

That’s not everything it takes to develop a new product and successfully launch it.

But it is a starting point.

And remember one of the big red flags I brought up earlier: Marketing and product not being aligned. When marketing your product make sure you’re talking about it honestly and transparently. If you don’t, all you’ll end up with is angry and frustrated customers and a whole lot of headaches for your support team.

Your customers are always changing and evolving. And without new products, it’s hard to see your (or any) company keeping up with that pace of change.

While new product development is always a risk, it doesn’t have to be. Follow this process, understand what your customers actually want, and continuously build, test, iterate, and market, and you’ll be in the best possible shape to create products people love.

Need help developing new products? At Sprintwell, we help purpose-driven teams design business solutions, products, and new services their customers will love. Get in touch!

Up Next:

9 Lessons Product Teams Can Learn from Formula 1 Pit Stops

9 Lessons Product Teams Can Learn from Formula 1 Pit Stops