Product Expert Malcolm Paul Explains the 6 Stages of Product Development

Understanding the terminology of each stage of product development and what actually happens in each is important for anyone involved in the process, from founder to developers to project managers. And if you’re new to product development, it’s information that you need to learn. WeWork Labs mentor Malcolm Paul, product management and development consultant at NITM, hosted a Labs session about technical project planning and roadmapping, including a primer on the different stages of product development. Here’s what your team needs to know.


What you’re working on: You’ve come up with an idea that you think could be a great product. Now you’re “asking questions, checking out your competitors, seeing who’s on the market—the basics. You don’t really have to like document anything—you’re just making firsthand observations,” Paul says.

The end result: “You have an idea that you’re excited about pursuing and your initial research suggests that it’s viable as an actual product that you can build a company around,” Paul says.


What you’re working on: Planning, validation, and prototyping. Your product isn’t in development yet—“it’s probably just visuals or a 3D printing if you’re creating a physical product,” Paul says. “This is where you need to start documenting your research. Who are your competitors? What are they charging, what are their core features, and how are you going to compete? You’re putting together your ideal competitive advantage,” Paul says. You also need to create your scope document and your business requirements. “If you have those then the chances of building something that actually matches what you’re thinking of increase significantly,” Paul says.

Where you’re working: On a local machine or local server of your developer or development team. Paul notes that founders should stay out of the development environment for now. In the early stages, “if you don’t let your engineers work autonomously then you’re going to find that you’re causing friction and micromanaging,” he says. “The people who work here reserve the right to do whatever they want.”

The end result: “You should have at least a prototype, your documents that explain what technology you’re using to build your product, the entire scope of the features that this product will have, your environment and toolchain, so what libraries are you using if you're building software, what components and manufacturers are you using if you’re building hardware,” Paul says. “At the end of pre-alpha you know exactly what it’s going to take to build what you're building and you have the details of who to go to when and what should be setup before you start going to alpha.”


What you’re working on: “The first slightly usable version of your product. This is where everything is being developed, most likely on the local machine of the developer or the 3D printer, and what you're doing is starting to build out the technology you need for your product,” Paul says. “Don’t expect anything you see today to be the same tomorrow. Don’t expect things to work smoothly—your product will break. The point of alpha is to be broken, to adjust and fix and refactor at the same time. There has to be an eye towards producing and delivering but customers should not see this.” Instead, you’re getting feedback from your team.

Where you’re working: Like pre-alpha, you’re working on a local machine or server of your developer or team.

The end result: “At the end of alpha you're coming away with the version that the team is comfortable with that implements whatever it is that you’re building in that version,” Paul says, “and you’re ready to take that into testing.”


What you’re working on: A usable version of your product, where most of your features have been decided on and can be tested. “In alpha, you validate with your team, and in beta you take that validation to your customers and ask for their feedback,” Paul says. “There will be bugs because the product isn’t refined; things may not work or they may break. But the performance is acceptable and the features are generally usable.” You need to consider the size of your team when deciding how many beta testers to recruit, because all of the feedback you get needs to be analyzed. “If you have a team that could manage 100 beta testers, get 100 beta testers,” Paul says. “If you’re solo or you have three people on your team, you might want to limit it to around 30 beta testers because you have to take that information and go back and reconcile it with your product.”

Where you’re working: For beta, you move from the development environment you were using for pre-alpha and alpha to a staging environment where the client or beta testers can test out your product. “It’s usually hosted on premises or on a cost-effective cloud solution,” says Paul. “It may not be; more likely it’s staging.companyname or test.companyname.”

The end result: By the end of beta, you should have a product you feel comfortable with and that people would potentially pay for. And you need to a way to keep your beta testers engaged for the future. “You might give them lifetime access for free, or certain features or an access level for free,” Paul says.  

Release Candidate

What you’re working on: This is your final version before you officially release your product. At this point your product is stable and you’re not adding new features—you’re looking for insight on what you’ve created from more potential customers. “You might have a certain amount of users who can see a release candidate, like when Google switches UIs and they invite a small number of users to test it out,” Paul says. You’re not explicitly asking those people for feedback— you’re monitoring how and if they use the product. “This gives you feedback on actual real world usage,” Paul says.

Where you’re working: Now that you’ve got public version of your product, you need to move to a production environment. “Production will be probably on Amazon Web Services (AWS) Scalable or Beanstalk, or something like a Google App Engine environment,” Paul says. “Ideally you want production to be automatically scalable if you’re doing a high performance platform and you want to be sure that people can’t log into the actual servers.”

The end result: You’ve got data and insight into how your product will perform and be used in the real world, and you can use that information to make final tweaks before you go to production/release.


What you’re working on: You’re releasing your client-facing, final version of your product. There are no bugs and your infrastructure is fully supported.

Where you’re working: The same production environment you used in release candidate.

The end result: You’ve brought your product to market. From here, you’re iterating new versions or features, and going through the product development cycle again for each one.

This post is based on content from a WeWork Labs programming session.

Interested in connecting directly with this mentor? Ask your Labs Manager for help.

You've successfully subscribed to WeWork Labs Insider
Great! Next, complete checkout for full access to WeWork Labs Insider
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content. Check your email If you are not already signed in.