Product development overview

Product development processes help teams avoid costly errors. While not everything can adhere to a process—some products are discovered by accident or through lucky mistakes—processes ensure teams waste as little time as possible. A process can save teams from building products that:

Each process outlines its own series of steps. In the design thinking framework popularized by the design firm IDEO, the process is to “empathize, define, ideate, prototype, and test.” In the CIRCLES Method™, it’s to “comprehend, identify, report, list, evaluate, and summarize.” Most product design teams use these models as a foundation upon which to create their own. Without a step-by-step process, it can be easy for companies to fall into counterproductive traps, like leaping to conclusions. Take, for example, a software product team that notices lots of users churning and invests months of effort into making the user interface prettier before realizing that the problem isn’t how the product looks—it’s that the software itself isn’t very useful. Had they followed a process, they might have spent their time more wisely. A good product development process acts as a filter for ideas. Once a true customer problem is identified, new ideas are tested for viability. For example, is the proposed solution desirable? Is it technically feasible? Is there a big enough market to justify its development cost? An effective process sifts out the bad ideas and only allows solid ones to reach production. A process also helps establish communication throughout the company. It lets all departments know when and how to contribute to the product. For example, it can ensure that all teams get input at the idea generation phase so the sales team doesn’t wait until the eve of the launch to point out a critical flaw. Diverse teams are key to successful product development. “Most product teams build the products they want for themselves,” said Mina Radhakrishnan, a former design leader at Uber. “But the more identities, backgrounds, and experiences represented by creators, the more problems solved, the more user perspectives understood, the more products launched by teams who have a handle on how the world will receive them.” Companies with a firm process and a diversity of ideas often outperform their competition. Don’t yet have a process? Here’s a sample framework any team can adopt.

There are countless product development methods, but most follow a simple pattern. They begin with identifying that customers have a need, dreaming up solutions to that need, building a product, and then launching it with marketing and sales.

Identifying a customer need is the most critical and most overlooked step in the development process. Teams often skip it—they hear customers complain and want to immediately find a solution—but this is like driving miles down the wrong road before checking the map. It’s much better to slow down, listen to customers, and try to understand the real issue. Sometimes, a customer complaint isn’t what it seems. For example, customers that say a product is too expensive aren’t always complaining about price. They could be saying is that the software doesn’t have enough features, or that they don’t understand how to use it. The real issue is that they’re not getting enough value, and there’s more than one way to solve that. A product team that leapt to conclusions and released a cheaper version of their software right away would simply cut into their revenue. But a team that dug into the problem and asked what customers they meant by “expensive” might develop new features that allow the company to charge even more. Broadly, customer needs come from two places: market research and experience. Companies can either conduct research to analyze customers and competitors to identify a gap in their product offering or they can learn about an issue from front-line workers like customer service agents.

Once the team has identified a real need, they can begin trying to solve the problem. There are plenty of ways to approach idea generation, but it’s best to alternate between coming up with as many ideas as possible—known as ideating—and then refining the list to just those that are feasible. Teams must keep an open mind because it’s often impossible to know which is going to work early on. Team members can sometimes resist ideas simply because they haven’t been tried before, and can accidentally rule out viable options. Google’s Project Loon, for example, currently uses hot air balloons to deliver wireless internet to areas of Peru. It’s called “loon” because it began as a joke—the team thought it was looney. But after extensive testing, balloons ended up being the most practical method.

Before teams build a product, they must build a business case to justify its cost. For example, are there enough potential buyers? Will they be interested? Can they pay enough to make the process of development viable? Here a few questions teams can ask:

After products are screened and there’s a solid, justifiable business case, it’s time to start development. Overall development is expensive, so teams may choose to create a minimum-viable product (MVP) that can be tested in isolation. Agile development teams often choose to build an MVP so that the product can be tested each time they commit new code. Once a functional MVP exists, companies can beta test it with a select group of customers. Ideally, this group is representative of the broader market, and the MVP offers enough utility to compete with existing products. During this stage, the product team can collect customer feedback, iterate, and improve its features to prepare it for release.

Contrary to popular belief, commercialization isn’t the end of the development cycle—it’s really the beginning. It’s only once the product or service is in the hands of actual customers that product, marketing, and development teams get their first real user data. Only then can they validate their business case and begin testing and improving the product with real customer feedback. For some products, and especially services such as software, the development cycle is never over. Salesforce, for example, has been developing it’s same-named core CRM product for its entire company lifespan, and has no plans to stop. Any product team embarking upon their own product development process should prepare themselves—if they want to outperform the competition, the cycle of innovation never ends.