4 Biggest Myths In Product Development & How To Avoid Them
Why are we behind schedule? When will you finish the product design? If you have heard those words before, you are not alone.
Many companies do not understand how product development works. They think of it as a linear process, as if throwing in extra resources will magically fix everything. In reality, it’s much more counter-intuitive and complex than that.
I have had my fair share of shooting down some of the common product development myths during my career. In a start-up environment, that can be very chaotic but rewarding at the same time. Think of it this way—it’s easier to fix something before it gains momentum.
But the challenge is to bring everyone on the same page before the damage is done. The last thing you want is a tug-of-war going on at your workplace. If left uncontrolled, it becomes another fire that won’t die out so quickly.
If you are into product development and are wondering where you’re going wrong, take a look at these common product development myths. It will help you stay atop your game.
- More resources mean better performance
- Working in large batches improves the development process
- Flood the product with features, and the customers will love it.
- Stick to the plan, come hell or high water
On To Some Professional Myth-Busting
Let’s get one thing straight—product development is an entirely different ballgame than manufacturing. In manufacturing, you can control costs and ramp up efficiency the conventional way. But if you do that in product development, you’ll end up doing more harm than good.
Why? Because production is predictable. Tasks are repetitive, like cogs in a machine. Meanwhile, product development is dynamic and ever-changing. There is no one right way to do it—you learn as you go. That brings us to our first product development myth.
Myth 1: More resources mean better performance
More input equals more output makes perfect sense, but that logic is dangerous and misleading in product development.
According to surveys, most product development managers keep capacity utilization above 98 percent. It makes sense that the more a team works, the greater the output it will deliver.
In practice, it doesn’t work that way. High resource utilization leads to poor team performance and lower output. No matter how good of a manager you are, you just can’t work your way around this. But many managers ignore this for two main reasons:
1. They underestimate how unpredictable product development is. A project can land on your desk at any time. You can’t foretell what kind of project it’s going to be, what kind of expertise you will require, and how long it’s going to take.
Product development is anything but linear. Adding high utilization of resources into the mix leads to more delays, hiccups, and queues. This is because if a team is always working at 100%, any new projects would have to be queued because there is no capacity buffer.
2. Managers routinely underestimate how bad queues can be for performance. When a product development team works at max capacity and juggles several projects at a time, it is bound to bench projects that get caught up in approvals and verifications.
Let’s say you are designing a product and mid-way, you can’t proceed because you need the go-ahead from the engineering department. Suppose this approval takes three weeks. What do you do? Sit around for three weeks or take up a new project for the time being? Most product developers do the latter without realizing they are only setting themselves up for disaster.
By the time you get the approval, you will be working on a different project and won’t have the capacity to take the project back on. As a result, the original project stays in the queue unless you free up some capacity to pick up where you left off. With that, the idle project runs the risk of becoming obsolete if market trends change.
Again, that is a consequence of high resource utilization. Working at max capacity creates longer queues. This vicious cycle continues until you either clear the backlog or increase your work capacity by setting up a new team. In other words, queues:
- Increase delay costs, process costs, and cycle times.
- Bench projects. The longer you bench projects, the more vulnerable they become to market changes.
- Make product development even more variable.
Here’s how you solve this resource-allocation conundrum:
- Limit the number of active projects. That will reduce your utilization rate, free up some capacity, and lead to fewer queues. More so, the team will become more focused on the tasks at hand.
- Make work-in-progress (WIP) inventory more visible. In product development, WIP is invisible, and that’s why it’s so hard to allocate resources effectively. I always found visual control boards really helpful in staying up to speed. You can have 10-minute meetings daily or use a lot of post-it notes. The goal is for everyone to be as vocal about their milestones as possible.
- Align department objectives. Consider again that example where you have to wait for three weeks to get an approval. What if it took just a couple of hours? For that, you need to sync departments’ objectives by changing management-control systems. Most managers want to increase capacity without realizing they can squeeze a lot of it out if they tweaked operations and made them efficient.
Myth 2: Working in large batches improves the development process
Working in large batches works well in manufacturing but not in product development. Large batches mean more queues, and more queues lead to higher work-in-progress and longer cycle times.
Suppose a team has to build 300 components of a machine. It can build all the parts together or work in batches of 20. If it decides to build all the parts together:
- Queues will be longer
- Cycle times will be higher
- Feedback will be minimal
A product development plan may not go entirely as planned. You’ll have to tweak technical specifications or some other feature of the product. The only way you ride this learning curve is through feedback.
Feedback is the information you learn as you test the product and see how it performs. It’s necessary to determine if the development process needs any changes based on technical factors. A lower feedback leads to longer cycle times. A cycle time is the time elapsed between design completion and production. You can measure it using Little’s Law.
In the second case, the batch size is 90 percent smaller.
- There is little to no work-in-progress
- No queues
- Rapid feedback
- Better quality, efficiency, and reduced cycle times
Many product developers take the former route, thinking that working in large batches produces economies of scale. But that’s far from true. Reaching an optimal batch size comes down to balancing the transaction and holding costs.
If you stock up on a year’s worth of eggs today, you might get a good price for it, but most of the eggs would spoil. In other words, you have a low transaction cost but high holding cost. The trick to getting the best of both worlds is to find the right balance.
Arriving at the optimal batch size is no walk in the park. It varies from business to business. For example, if you have a grocery store, your holding costs will be much higher than a steel manufacturers. The bottom line is, go for a batch size that will not create new bottlenecks and costs you the lowest.
Related Read: How To Create An Effective Customer Feedback Loop For Product Teams?
Myth 3: Flood the product with features, and the customers will love it.
Product developers routinely assume that the more features they throw into a product, the more customers will like it. This is far from true. How many times have you picked up a product and found it was too complicated to use?
It happens all the time. Typical headphones have too many buttons on the side, TV remotes are difficult to use, LCDs are cumbersome to set up, and wireless charging is still a fantasy. Still, it’s hard to convince a product developer to keep it simple, and that’s mainly for two reasons:
1. Product developers tend to brainstorm so many ideas without narrowing them down. I have noticed there’s usually a lack of a filter. It’s like how a workaholic can’t stand seeing an empty slot in their day. They need to fill it with something productive.
The same way, product developers see an opportunity whenever they find an empty slot where they can add in more features to a product, regardless of whether the consumer will ever use them or not.
Apple Inc. is a great example of the opposite. It always keeps simplicity and elegance at the forefront. Product development starts from the end-user and works its way back to technology. In other words, the consumer drives technology, not the other way round. In fact, Apple’s design team has the final say before a product is released into the market.
Stacking unnecessary features into a product doesn’t add value to the customer. McKinsey reports that most companies “monitor customers’ satisfaction with product performance [and] only 44 percent of them measure customers’ satisfaction with the price they paid for the value they received.”
Companies that relied more on the latter metric fared better in terms of both short- and long-term profit growth and stability. Meanwhile, those that only focused on product performance missed out on long-term growth.
2. Product developers love flaunting their expertise. So much so, they sometimes forget that it’s more about the customer experience than the technicals. All consumers want is a seamless user experience, a solution that works effortlessly.
To do that, product developers must know what to omit. Put yourself in the consumers’ shoes. Would you want to buy a refrigerator that has a built-in audio system? At first, it sounds cool, but it’s just cumbersome to listen to songs on a refrigerator.
Narrow down your list. The product features you choose should either be essential or make the product stand out. Remember that a product isn’t finished when you can’t add any more features, it’s finished when subtracting another feature would make it worse rather than better.
Here’s an example of the process I used when working with UX/UI designers to build a simple and easy-to-use app for retailers.
- Engage in ideation, which basically means asking the right questions and answering the ‘hows.’ Here’s the opportunity to step beyond the obvious and look for innovative solutions by bouncing ideas off your team. We also set a time limit so we don’t get overboard with it. You don’t want to trade-off creativity for time and efficiency.
- After narrowing down your vision of the final product, I think the most important step that most developers miss is to start from the end and reverse engineer your way back. That helps you figure out all the steps needed to get to your final product. Most developers start from scratch and end up losing sight of what they had originally planned.
- As mentioned earlier, the product development plan can change and it does. In carrying out all the steps, the brainstorming is still happening, except that now it’s specified to the technicalities. Think of it like fine-tuning your originally conceived idea and taking it to the next level.
Myth 4: Stick to the plan, come hell or high water
As the saying goes, “the best-laid plans of mice and men often go awry.” This couldn’t be more accurate. From start to end, product development is all about trial and error. Experimenting allows you to recognize the loopholes you oversaw earlier.
An MIT study reveals the dynamic nature of product development. Aerospace engineers working on a subsystem looked at multiple designs before selecting the best one. However, throughout the engineering process, their preferences changed based on the test results.
Product development is all about innovation. You start with an initial conception of the product and tweak it as you go. Maybe the glass back of the phone heats up too much, or the curved edges won’t allow the GPS antenna to fit in. You only gain these insights once you start testing and experimenting.
As discussed earlier, product development starts with the customer, not the technology. But how do you gauge what the customer needs? Most dissatisfied customers don’t complain about a product, they just leave. Worse yet, what if a customers’ preferences change along the development process due to evolving market trends?
The answer to all those questions is that you change your development plan. That doesn’t mean planning is futile; it means you need to be meticulous down to the very last detail. Treat your plan like a hypothesis rather than a law because, at the end of the day, you don’t want a perfect plan, you want a perfect product.
Here are some things you can do to keep your product development plan more flexible:
- Develop an overarching plan. Consider it like a skeleton, a basic structure that will guide your development process. Leave out the details because they’ll fall into place eventually. You might even have to tweak the basic structure to accommodate some details that are absolutely essential to your product.
- Expect flaws in your plan. You can’t possibly foresee everything. That’s why your plan should have enough cushion for you to fall back on. Carve out alternatives to the basic structure you’ve already built.
Related Read: Best Product Planning Software
Some Parting Thoughts
No doubt, product developers are tasked with some of the most difficult jobs on the planet. Innovation needs time and lots of experimentation. You can’t treat it like some run-of-the-mill process such as manufacturing or production. As a product developer myself, I can testify most managers don’t understand that. They live inside these myths, and someone must pop their bubble.
As exciting as product development is, it can be equally frustrating and draining whether you've got a person for every job or managing products without a complete team. The key to staying atop your game is to do away with the above myths. If you are a new product manager, we just saved you countless headaches and pointless meetings. If you are an experienced professional, don’t hesitate to share some other product management myths in the comments section below.
For more insightful product management articles and tips from industry experts to keep you ahead of the curve, subscribe to The Product Manager’s newsletter.
Or, listen to some of our podcasts like this one: Cultivating Momentum (with Paul Ortchanian from Bain Public)