As a product manager your job is simple: identify opportunities to build products that meet customer needs and work with engineering to build and ship said products. Right? Unfortunately, delivering an effective, simple solution is a lot harder than you think.
Too often, products are made way more complex than they need to be. This is what is called overengineering, and it’s a real problem for product management. Overengineering can cause your development process to slow down, resulting in a product that reaches the market well past its prime. It can impact the end user experience through bloated web pages, clunky online checkout process, or too many features.
Regardless of the reason, the major risks associated with overengineering can include anything from missed timelines, high costs, or lack of engagement with the product. This article provides you with everything you need to know about overengineering so that you can identify and actively prevent it within your product team.
Simply put, overengineering occurs when you build a product that is way more complex than it needs to be for a user to find value in it. Overengineering a product can be very expensive, leading to extended development timelines, the accumulation of tech debt, and lack of a product-market fit.
To help you understand it fully, consider the following example of how overengineering might happen. As part of the product development cycle, you understand customers needs and pain points and create solutions that aim to fulfill those needs. Although this seems simple, as the discovery process goes along soon you start to identify all these other things the product should and could do.
You start to think about how the product scales for the future and the overall performance of the product. Customers are requesting the product do everything under the sun and more. You meet with engineering outlining all of your findings from your research and seek input from the team. They raise concerns about supporting old code, handling load, building new components and more.
Before you know it, that simple product you were going to build and ship becomes much larger, timelines extend, the costs of rebuilding and performance testing increase, and everything seems out of control.
So how can you, as the product manager, identify upfront potential overengineering efforts to avoid negative results?
The most common causes of overengineering include:
There are two causes for this. The first stems from not setting a clear vision and goal. Ask yourself where you want to be on day one? What does the end state look like a year or two from now? Without this clarity up front it’s hard to ensure you’re building the right experience at the right time.
The second occurs from a lack of communication with all the right people. In this scenario you have a strong vision and goal set for the product and leadership remains aligned. However, you fail to communicate that vision and the goals effectively with the engineering team either through sharing insight into the product current and future states or vague product requirements. This leads to your engineers having to fill in the blanks on their own (often without you realizing) as they implement the feature.
If you had all the time, money, and resources in the world you could build a pretty amazing product, but sadly, the reality is you don’t. Engineering comes at a high cost between salaries, time spent working on one product over another, tooling, and more.
Not being upfront with your release timeline can cause your engineering team to approach the product in a totally different way. Everyone wants to be proud of their work. If given the space, engineering might go overboard and create a new, optimized species of animal when all you really needed was a coat of lipstick on a pig.
Customer research and validation is so important to the success of your product. Make sure you let your customers tell you their problems. It’s your job as the product manager to take all that information and figure out where the biggest need or pain is and start with just that. You have plenty of time after releasing to further validate that use case and gather feedback to build additional features.
Factoring in the future vision of your product and its utilization is very important. However, in your initial release it’s vital to evaluate how much you need to really worry about that scale now versus later. Yes, being able to handle high traffic volume, performance, and load may be important to you up front but without the right sizing usage and being realistic about the scale and timing, you could end up building a fortress when all you needed was a cave to start.
Alongside the common causes, overengineering also comes with a set of associated risks. The following are some of the most common ones:
Adding too many bells and whistles before launch is a huge time drain. On your first pass make sure you understand your customers needs and identify the minimal viable product (MVP) you can build to address the need. Adding too much complexity or scale up front without validating your customers can cause massive delays in release timelines not to mention a lot of additional code to support.
Spending too much time overbuilding a product not only lengthens the time to market but can come at a steep cost. Costs can be associated with the number of resources (engineers) working on the project. Increased data storage could result in very high costs, performance testing, and continued support for the product.
By overengineering your product from the start, you put strain on support and engineering teams because of the expanded surface area and code they have to maintain. If the product is too complex, you risk increased calls to support from customers and increased time spent debugging issues instead of building products.
As a product manager, you can help to avoid overengineering if you:
As you communicate the product and the requirements with engineering, work with your team to align on your vision for the product including short term milestones and validated long term direction. Make sure to relay any deadlines to consider so everyone knows when features need to ship.
When setting your product requirements, make sure to give them priority. Identify what parts of the product are the most important and what you can delay and reevaluate based on demand. This not only helps you prioritize but also keeps your team focused on the most important work.
You need to strike a balance with your team in building for the now with an eye toward the future. While building too much up front to scale is a problem, you also don’t want your engineers creating hacky solutions that end up resulting in accrued tech debt and throwaway work in the future. Having these proactive discussions with engineers allows the team to come to a shared understanding.
The following examples from real-world companies help illustrate the importance of preventing overengineering in your product teams:
Google set out to innovate by creating wearable voice and motion controlled Android glasses. While its intentions were high, unfortunately Google spent a lot of time jam-packing Google Glass with features without really considering the core concerns users could have around security and battery life.
Not only that, the glasses came equipped with a wide array of features that weren’t necessary or practical for a pair of glasses. Between not meeting customer expectations and the steep price point, Google ended up discontinuing the glasses in less than two years.
Back in 1985 Coca Cola decided to go head to head with Pepsi by creating a new coke formula that would more closely resemble the sweet taste of Pepsi. It called the product “New Coke.” However, shortly after release of the new formula, consumer rejection poured in.
It turns out customers who liked the original Coca Cola taste didn’t want the flavor profile to be similar to Pepsi. In fact, for many the original taste of coke was not only familiar but nostalgic. In turn, Coca Cola ended up shelving New Coke in favor of bringing back the original taste.
Overengineering products can be a real issue for product managers. Luckily, experience and proper planning can minimize the chances of this happening to your next product. Review the common causes with your team and help them keep an eye out for them.
Remember, always communicate your product vision and goals along with how and when you plan to deliver them. Doing so can go a long way with building a simple, elegant product your users will love. Good luck and come back for the next article.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
