In the waterfall era of software development (and, unfortunately, still today) people focused on three factors for software delivery: scope, time (schedule), and cost. The conventional wisdom at the time was ‘pick two’. Adjusting these variables generally had a direct impact on quality.

Today, Agile methodologies and continuous delivery have offered solutions to help mitigate scope and schedule. Now, the cost is in the communication and collaboration between members of the team. We have a different trinity of concerns: design, engineering, and product management. Here I’m sharing how each function fits into the puzzle.

1. Design (and the Steve Jobs school of thought)

‘Design is not just what it looks like and feels like. Design is how it works.’ – Steve Jobs

Design is often interpreted as primarily visual. It’s easy to understand why people focus on this area; humans tend to be visual creatures and have strong reactions to aesthetics. People can often understand and communicate about the visuals of a product, even if they don’t understand how things work under the hood. They may not know much about design, but they know what they like.

Successful tech companies have capitalized on this and use visual design as a lever to drive priorities and direction. But by doing this, they lose some ability to use design to serve actual customer needs (or jobs-to-be-done). Said another way, form follows function.

Designers, like engineers, are problem-solvers. The best of them attempt to understand the problem deeply, identify several possible solutions, and then focus on the best possible solution given the current context.

While Jobs’ quote is fairly well known, there is an equally famous quote that complements it and highlights what many designers strive for in their work:

‘A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.’ – Antoine de Saint-Exupéry

2. Engineering (if you build it, they might come…)

One of the great conceits of engineering is thinking that most (all?) problems can be solved with technology. Social media is potentially a lagging indicator of how untrue this is, especially when examined through the lens of underrepresented people. There have been a tremendous number of technological breakthroughs over the decades and that should not be diminished. However, the most significant advancements have come through a marriage of technical excellence and empathy for users. Products such as the Mac and the iPhone are examples of this and reflect why Jobs stated that Apple tries to be at the intersection of technology and the liberal arts.

It’s incredibly rare to find engineers that are both great designers and great engineers. The days of the lone genius toiling away in their garage and producing the next great product are long behind us (if they ever existed at all). Software development is a team sport and some of the best teammates on the engineering side are T-shaped engineers; T-shaped engineers are generalists that tend to have a breadth of technical knowledge with a depth of knowledge in one area. These engineers tend to pair well with designers to solve for the jobs-to-be-done (i.e. serve customer needs).

3. Product management (p is for product, not project or program)

One of the most ambiguous abbreviations in our industry is PM. It’s often used interchangeably for project managers, product managers, and program managers. Over time PdM has surfaced as an alternative for product managers and PgM for program managers. Still, PM is commonly used to refer to any or all of these.

In the early days of Microsoft, program managers could very easily be considered product managers as the expectations of the job had significant overlap. As more companies adopted the program management role, the definition of the job evolved distinct from product management.

Many people, myself included, promote the idea that product management is responsible for the what and the why while engineering and design are responsible for the how. Fans of Marty Cagan would go further and say that product managers are expected to have deep knowledge of:

• Users and customers (yes, they are different groups)
• The data
• The business
• The industry

Product managers that lack deep knowledge in these areas will find it hard to succeed both in being responsible for the what and the why and collaborating with their peers in design and engineering. Product management is critical as it functions as a bridge between the execution aspects of design and engineering, and the stakeholders representing the needs of the business.

Working together as the trinity of software development

People often cite friction between the roles of design, engineering, and product management and assume that to solve this one of the roles needs to be dominant. This leads to design-led, engineering-led, or product-led strategies that solve for the wrong problem. The friction people witness is simply the natural creative tension between the disciplines. All three disciplines must be engaged to solve the jobs-to-be-done, and often solutions focused on one front will be at odds with important factors from the others.

Instead of trying to avoid or eliminate these tensions, we need to embrace them. That can only happen when there is mutual and genuine respect for the value each discipline brings to the table. For example, I’ve frequently surprised my design and product management peers when I tell them to not compromise on their vision or worry too early if something will be ‘too difficult’ for engineering to pull off. When we start from a position of compromise, the end result often reflects that. Instead, when all sides shoot for the ideal, it tends to force dialogue and understanding follows from that. Compromise is going to happen regardless, so all sides might as well aim high. A healthy and respectful environment will allow dialogue and compromise to occur and thrive. This is the type of environment that allows empowered teams to deliver their best work.