What are the Product Development Process stages you’ll go through to get to market?

Product development takes place not only in the earliest days of a startup but every day after launch, as well. It’s crucial to have a process and team that are built around learning from customers and constant iteration. 

In this post, we’ll cover the basic tenets of the process, the stages you’ll go through to get to market, and some guidance on hiring a product development team.

Product development and the product manager’s role

Product development is the process of creating value. You’re building something useful, hopefully mission-critical. You’re building whatever you need to solve problems.

Your role as product manager is to do so in the leanest way possible. (More on that below!) While keeping the product lean, you’re also discovering the broadest range of potential problems, so that you know your final solution is the most effective and interesting that your company could be doing.

Why? So that you don’t waste time building something that is subpar, or that doesn’t actually solve the problem, or that isn’t going to be loved by customers when you actually put it out there.
The final version you end up with could be completely different from where you started, but that likely means it’s stronger, more stable, more viable.

The process involves: 

• Discovering and listening to your customers. What kinds of problems do they have? They’ll help you gain a broader understanding of things if you ask the right questions. Give them access to MVPs and feedback channels.
• Prioritize the problems. Identify ways they could be solved, and tie those possibilities to business objectives. Because any solution you choose—any route you take—must also allow the business to hit its own goals and grow sustainability.

You shouldn’t approach product development with only business objectives in mind. Again, you only learn what you need to build by talking to your customers. As Jeff Patton says, “You can’t solve a business problem, you can only solve a customer problem.”

If you know how to solve a customer’s pain point, then you know how to earn some revenue.

The importance of an MVP in product development

Minimum viable products (MVPs) allow you to test your assumptions before you waste time on the wrong thing. The purpose is not to create an actual product, in the ultimate marketable sense, but rather something that’s more of an experiment.

You can use MVPs to test a hypothesis. For this, it doesn’t need to be a fully fledged feature, but could be as simple as a checklist item, a survey, or a short-term manual workaround.

Testing with MVPs is a crucial stage of your initial launch (which we’ll get to in the next section), but also an ongoing practice as you add new elements and solutions to your product.

Product development process stages to get to market

Here’s a quick rundown of the general stages your team will go through to get your product to paying customers. These stages might look slightly different depending on the company, but all teams go through some version of the following:

1. Understanding your market. What exactly are you trying to achieve? Track your success against that. This stage also includes discovering other solutions out there and knowing what your competitors are up to.
   
2. Testing it with MVPs. Yes, more than one. The final product vision can be sliced up into multiple MVPs. For some of these, you’ll have multiple iterations because you won’t get it right on the first go.
   
3. Put it to the people. Get customers using your product, and be ready to learn and iterate! This stage includes lots of discovery work, lots of prototyping, lots of feedback. That means there’s also a lot of changing the code, changing your focus, changing the service model. Adapt and keep moving.
   
4. Actually getting it to market. “If you build it, they will come.” Well, it doesn’t work like that for most products. You need to continuously encourage people to sign up. Iterate on marketing messages as much as you do the product itself. (Much of this can be done before you launch, and should be, so you aren’t surprised if certain messaging doesn’t resonate. But you should keep revising your marketing message after you launch as well.)
   
   There’s no test like production; you’ll learn the most once it’s live!
   
5. Getting paid. Actually, there’s no real test until you ask for money. It’s easy for people to say they would pay for your product, but handing over their credit card details is another thing. Money is the literal proof of value. You need people to show they’d actually use what you’ve built!

In summary, the stages to get to market mirror, in a way, the ongoing cycle of product development process in general. There’s no such thing as a finished product. Your team’s job is to constantly learn, iterate, and validate! (And get paid.)

Building a product development team

When building a workforce around your product, the most fundamental — and these days, much discussed — question is around whether to hire in-house or remote, whether to offshore or nearshore your product and development teams.

There are benefits and drawbacks to both on-premise and remote, of course. My belief is that the closer you work with your development team, the more you’ll catch questions around feasibility. There’s less of a need to document everything from the get-go as you figure out what to build next. All in all, you avoid wasting time trying to build the wrong thing.

The main benefit of a remote team is that you can hire great talent from anywhere. You can find the exact match for your needs and at your budget. But then, working in different time zones can create friction and obstacles… which persist despite all the new tools and technology for distributed teams.

Personally, I like the option of shared space, looking at the same wall, or the fun of a coffee shop lunch or pub to chat over potential solutions. Such spontaneous moments have been hugely valuable to us at ProdPad, and they just don’t happen in the remote, digital world.

The best solution is a blend. Everyone needs some alone time, some collaborative time. Some time on-site, some off-site.

That said, the problem isn’t necessarily where the team is located but whether they’re actually part of the team.

Outsourcing has become a common practice, which means the “team” is just a service provider whose goal is to deliver finished code. This depends on the requirements you give them. Their desired outcome is to execute on those requirements, not to meet overall goals of the company or even user satisfaction.

On the other hand, when the team is part of your company, their outcomes are your outcomes. They help shape what comes through the pipeline, and ensure the code that’s delivered is geared toward overall goals.