New Product Development: Get It Right [12/100]

I don’t have thousands of products in my portfolio. But I do have an informed opinion on the best practices in product development. When launching a new B2B product, these three rules should be followed.

1. The high density of communications during the development;
2. One year for the first release;
3. Growth through independent teams.

All other practices should only elaborate and extend these rules.

Now, let’s discuss! 👇

High-density communications 💬

A good communication process is only possible in small cross-functional teams of experienced specialists. I’ll explain.

In the first months of working on a product idea, communication process density is crucial. The ideal situation for the new product development is one developer who is also a domain expert. This person would generate new product innovation ideas and move forward as quickly as possible, plunging into the flow and emerging from there to get some food and sleep.

Unfortunately, such geniuses are not very common (though they exist). The smaller the team working on a product concept, the tighter the communication—the more the team can replace one such genius. Discussions of important issues—crucial for the new product development process—happen spontaneously, and answers are found quickly. Having just a few people is usually enough to start a product. Even when there are ten people in a team, the communication density drops dramatically, making the product development process all muddled. The team splits into several groups with weaker connections between them.

I’d say the maximum number of people in a new product development team is eight.

Then, we need to remove all things that mess up communication. For instance, different time zones get in the way of communicating quickly, so being in the same time zone is better for a new team at the stage of idea generation and validation.

All people should speak at least one common language. People should be able to express their thoughts distinctly—that’s a necessity for the new product development process. Otherwise, loads of time will be wasted to simply reach some common understanding of the new product idea.

Obviously, all these people working on a new product are better off sitting in the same room because remote communication is always less dense.

Team composition for new product development process

At the very beginning of the product development process, the team needs one domain expert who understands well what exactly it is you’re all making. You also need a designer to work closely with that domain expert. All other people are developers (or scientists, if your project requires such expertise). No need for QA engineers, marketing experts, or any other types of people now.

Such a team is small, but its size must be compensated by the expertise the developers have for making a sound prototype. It’d be nice if all developers are equally experienced and skilled—otherwise, their communication won’t be quite effective already at the ideation stage.

The more experienced the developers, the better for the final product. At its best, the developers should have from 10 to 20 years of experience. They already understand where you can cut off a corner in a project and where not. They know what the second system syndrome is, how to go about prototyping, and why you can’t trust Fowler blindly.

I believe that at the start of a new product development, in terms of productivity, one small cross-functional team of experienced professionals can outperform about four teams of mid-range developers. Moreover, mid-range developers may not even be able to solve the problems the first months of development bring. So yes, a small, highly-experienced team for new product development or nothing.

3 months + 9 months = 1 product launch 🐣

Don’t rush to immediately implement features like login and user management. You first need to spend several months analyzing everything. The team should find several solutions for the brave new idea and, if possible, to test as many of them as possible to choose the best one. This takes time. The most important thing (and I can’t emphasize this enough) is to formulate the problem well. A correct formulation contains the lion’s share of the solution.

Prototyping, in turn, is the best way to test solutions and see if they satisfy customer needs. For sure, it’s not a real final product, but at least you can touch and twist some things. You’ll need both a functional and a technical prototype. A great practice is to make videos out of the functional prototypes and show them to the potential customers. You can launch a website and track registration to see if people want to try the product. This won’t tell you whether the product is needed, but it, at least, will keep the designer and the domain expert busy while the programmers are working.

Yes, a year for concept testing and product launch

It is highly desirable to have the first product launch within a year. Even a very closed beta testing version for just one client counts as production. You see, a release is the only way to get some actual feedback. Prototypes, videos, interviews, conversations—these are all surrogates. They very often generate incorrect, incomplete information about the target market and the quality of your new product. Clashing with reality is the only way to get what you need.

Besides, working without releasing your product for more than a year is psychologically devastating. A year is somewhat the ultimate period you can spend working on a new product without losing enthusiasm or sliding into emotional breakdowns. If the release to test market takes, say, two years, be prepared for the productivity to drop and your programmers to have actual burnouts.

Growth 🦄

When and how to start scaling the team around your innovation? I would only start doing this after a public release and getting the proof of product viability. The architecture of your new product must provide for the independence of the components (low coupling, high cohesion). New teams should be made responsible for the fairly independent components by agreeing on communication process protocols.

I believe in Conway’s Law. Monoliths scale poorly: because huge teams are ineffective, and independent teams have trouble coordinating their actions in the monolith. Therefore, it is necessary to work on a modular architecture from the beginning and understand which parts of the system can be delegated to new teams.

It’s difficult, takes time, and, normally, nobody bothers to think it through at the stage of concept development. Everyone makes f#cking monoliths to save time. Why think about growth when the future of the product is so uncertain? In fact, this is an acceptable strategy, too—you just need to understand that as soon as you want to grow with a monolith, you’ll need to rewrite everything completely.

Long story short, you need to launch a new product with a small, dense, unallocated, highly professional team in one year. You start with SEALs and unleash your regular army later. 🤺

---

🎷 Let’s be friends on Twitter.