How Company Culture Affects Product Development
By Steve Owens
Product development not only requires strong technical skill but it also requires great creativity. Creative people are rarely concerned with details.
CMs (Contract Manufacturers) are amazing—they can do ten thousand things and not make a single mistake. Their business must work this way to stay competitive.
Product development, on the other hand, is different. In product development, you are lucky if you do ten things and get one right. For example, I just spent many hours researching a dozen Bluetooth ICs, and only one was chosen to be included in the product. I got one right out of twelve attempts.
Some would say this is an unfair comparison—and that is exactly my point. You cannot compare product development to other business functions. Other business functions are largely doing the same thing repeatedly. Product development is, by definition, creating something that never existed before.
This difference, as well as many others, has implications for company culture, and culture is driven by the actions of the leadership of the company. It is common, especially in smaller organizations, for the background of senior management to exclude product development and this lack of firsthand experience can cloud one’s perspective. Product development is difficult and requires a functional team if it is to be done well—not a place for a leadership vacuum.
The Mindset of a Product Developer:
I hate to stereotype people—it’s completely unfair. Each person is an individual and just because they are a member of a group does not mean they share all of the attributes of that group. However, any discussion of managing the culture in a product development team must include some thoughts on what you are likely going to run into; besides, I am a member of a group, too, and everything I am about to say is true of me as well.
Technical people, who make up the majority of a product development team, are very talented people—at least more talented than the rest when it comes to technical knowledge. They have spent years developing their skills. Few people have the drive or temperament for such tedious activity. Detail-oriented people have an advantage when it comes to learning the details of a technology to the degree necessary to design products out of thin air.
Product development not only requires strong technical skill but it also requires great creativity. Creative people are rarely concerned with details. This is why product development typically involves at least one creative person (the inventor) and one detail person (for more information on this subject: https://www.finishlinepds.com/invention-vs-engineering), although sometimes they can be one in the same person, for example, Steve Jobs.
It is not unusual for product development engineers to believe that they are special—and they are. However, this egocentric point of view can become the source of dysfunction for the team. It can spawn beliefs that only they have the ability to contribute, and that their ability is a priori.
It’s no secret that nerds (engineers, scientist, programmers, etc.) are not best known for their social skills. They have been described as being socially awkward, rude, insensitive, boring, condescending, and so on. Many are on the Autism Spectrum (what used to be called Asperger’s Syndrome). Given their behavior, it’s easy to conclude that they do not care about other people—which turns out to be completely wrong. Most are truly the nicest people and care deeply about others. They just don’t always know how to communicate this, and often accidentally communicate the opposite. Of course, there are many engineers who have great social skills, but my experience is that these engineers work in areas other than product development. Without strong leadership and management of the culture, this weakness can prevent the team from reaching its full potential. For more information see this link: http://www.independent.co.uk/life-style/health-and-families/health-news/autism-experiment-reveals-people-in-technical-professions-are-more-likely-to-have-autistic-traits-a6719956.html
One of the keys to any leader involved in product development is to understand who the people are and are not, that they are leading. What may have worked in different departments may fail in product development, especially if the true intentions of each person are not understood correctly. What follows are classic pitfalls of leading a product development team. Keep in mind, these same pitfalls may be highly effective in other settings, just not in a product development team.
As a leader, we want to be a role model for behaviors we wish others to emulate, reward those same behaviors, and ignore dysfunctional behaviors. Most leaders understand this model and execute it well. However, in product development, the types of behaviors that lead to success are not always obvious. What follows are some insights into the types of behaviors that should be reinforced in a product development team.
Failure is not an Option:
Anyone who studies sports psychology will tell you that confidence is a major driver of performance. “Winning isn’t everything, it’s the only thing,” as the mantra goes. The corollary in business is “Failure is not an option.” These ideas are used to motivate and build confidence (or at least weed out team members with low confidence) and can be effective in creating success.
However, motivation and confidence are not lacking in most product development teams. One could argue that the amount of motivation and confidence is already too high. Close attention to detail and egocentric thinking are natural qualities of most product development engineers. In addition, motivation and confidence are not key determinants of product development success—effective decision making and risk management are.
Leaders of product development teams should avoid behaviors that ignore risk (damn the torpedoes and full steam ahead) and instead model and reward behaviors that contribute to effective decision making and risk management. Be careful to not reward or model these types of behaviors:
- Risk avoidance or dismissing risk (which is not the same as risk assessment)
- NIH Syndrome (see below)
- Knowledge hoarding
- Focusing on personalities: we need to make good decisions, not like each other (although this will happen over time if the team creates success)
These behaviors should be modeled and rewarded:
- Collaborative Decision Making (which does not mean there are no clear roles and responsibilities)
- Respect for others’ ideas (meaning, you give careful, well-articulated thought to all ideas regardless of the origin)
- Success is more than just technical
- Clear roles and responsibilities (which does not mean you cannot also be collaborative)
- Risk assessment: we understand the risk and plan to minimize failures if they happen
NIH (Not Invented Here) syndrome is part of the genetic makeup of most technical people. Worse, the more brilliant the person, the stronger NIH Syndrome takes hold. Brilliant teams can be even worse as they each reinforce the belief that because they are the “originator” of the idea no “other” can contribute to success. This dysfunction can even have subtler aspects, for instance, the belief that whatever expertise the person/team possesses is the only skill set that will make a difference.
Be careful not to reward/model these types of behaviors:
- Dismissing the competition as being clearly inferior
- Starting a project over when a new team is assigned
- The product will be so great it will sell itself.
- Starting a design before an understanding of the requirements
- Sacred Cows, the emperor has no clothes, sunk cost fallacy, etc.
These behaviors should be modeled and rewarded:
- Reverse engineering competitive products
- Spending time and money with marketing to truly understand the requirements
- Budgets for consultants and outsiders to attend design reviews, especially during the conceptual design phase
- Setting the expectation that several concepts will be generated and formally compared and contrasted with the requirements
The Budget Goal:
In some companies, the budget can become the goal. In most business activities, this is not a bad attribute. If we can get the same work done for less money, then we will make more profit. What can be more logical and important than this concept?
In product development, the same thing is never done again. The objective of product development is a large ROI (Return on Investment). Any money spent on product development will detract from current profitability, but MAY generate more profit in the future. Hopefully a profit is generated (the project actually makes it to market) and the NPV (Net Present Value) of this profit stream is a lot higher than the investment. Focusing on “the budget” can lead to poor decision making, much like buying penny stocks because they are sooo cheap and ignoring the value part of an investment equation. Price is what you pay, value is what you get.
There is related dysfunctional behavior where the budget is really the money spent outside the corporation. After all, the cost of the employees is not something the team can control—or we should not even know what other people make. If your culture never outsources, you are likely managed in this way. Ninety percent of any budget in product development is the cost of employees. It is not credible to say your team can be world class in all the activities that will be required to develop a product, especially in a small company. But if employees are considered “free,” it will appear that way to the team.
Your role as the leader:
- Track and communicate to the entire team:
- the “true cost” of the development
- the anticipated return from the development
- the ROI criteria
- the average hourly cost for engineering
- Focus new hires on “core” skills—those skills for which you can be truly be world class
- Encourage outsourcing/partnering/buying any skills and technology that are not core to your business
- Encourage shutting down any project that the team believes will not meet the defined ROI
- Encourage defining a different budget if doing so will have a higher ROI, and cash flow can support such a budget (assuming the new budget is higher)
A culture that sees product development as an investment will make better decisions than ones that just manage to the budget. They will manage product development as a basket of diversified stocks (projects). They will sell (shut down projects) stocks whose prospect for higher returns have diminished and buy more stock of the ones whose prospects for a higher return have increased.
The Prototype Goal:
Prototype goal dysfunction is where the entirety of the development effort is to produce a “working prototype.” Often the definition of “working prototype” is ill defined, and even when it is defined lacks the kind of clarity necessary to produce a product that will lead to a positive ROI.
This particular dysfunction is more common in small companies and startups where product development procedures are immature. It is less common in large companies that have completed multiple projects and have developed procedures to manage this process.
Even if the goal is to produce an MVP (very common with startups trying to validate markets), the goal needs to be defined in term of technology, market, compliance, unit cost, developmental budget, etc.
With this dysfunction, the product development goal is replaced with the idea that the only result that is important is a prototype, which translates into something the engineer is able to show in a dog and pony show. The engineer is given the task of “building the prototype” without regard to requirements from the rest of the organization. It is assumed the engineer either has or can create the entirety of information necessary to construct the product vision and requirements. The engineer is happy to spend months, if not years, in isolation working on getting the prototype to work. However, in almost all cases, the expectation does not get to the promised land. Sadly, this usually results in the engineer’s departure, and another engineering victim is hired to repeat the same flawed process.
Product development is not just making a working prototype. Product development consists of step-by-step processes. Skipping steps is going to increase cost and time.
- Define the goal in a clearly define requirements document (link to template can be found here: https://www.finishlinepds.com/tools )
- Articulate and require team members to follow a well-defined product development processes
- Set clear short-term goals
- Assess the status of the project by reviewing the progress of each short-term goal
- Socialize the idea that the product requirements will likely change as the project progresses
Culture is an important ingredient to any product development project. Projects will not succeed on technical skill alone. Engineers do think differently than most of the rest of us. These differences mean different leadership skills will be required to develop a culture that allows for the sum of strengths team as compared and contrasted to the sum of weaknesses team. With the right framework and insight, this goal can be achieved. It is likely this framework is different than what has worked and will work in different business activities. Leaders new to product development should understand these differences and adjust their thinking accordingly.