Resources > Articles

Ask the Experts: Who Owns Design?

Author
  • Paul Young

    Paul Young oversees the strategic development of Pragmatic Institute’s portfolio of products and leads the executive team in the evaluation of new product opportunities. He also manages the instructor team. Paul began his career as a software developer and has worked in startups and large companies across B2B and B2C industries, including telecommunications and networking, IT and professional services, consumer electronics and enterprise software. He has managed P&L lines for products with hundreds of millions in revenue, and faced difficult choices about which products in the portfolio to retain and which to kill. Reach him at [email protected].

design

This is one of the questions I receive most frequently. Should designers report to development, engineering, product management, marketing or someone else?

Or should design be its own group?

To answer the question, we must first define “design.” Even that has been heavily debated, but for now, let¹s use my definition of design:

Design is the role in a team that understands a market problem, and comes up with a solution to that problem. 

At a minimum, there are two flavors of design:

Front-end design. This is what most people mean when they say ³design.² The titles found in front-end design include user interface, user experience, human/computer interface and human factors designers. These are all titles found predominantly in software projects, but front-end design is not limited to software.

Front-end designers in hardware applications are concerned with ergonomic design, user fatigue, eye level, placement of power cables and interfacing to larger systems. In services, a front-end designer might think about how many key presses a user makes on their phone when calling into an interactive voice-response system before they can talk to a human.

Back-end design. Those involved in the back end are often called “architects.” In software, they are typically concerned with items like codebase choice, code reuse, library selection, building scalable and secure systems and whether to use Amazon EC2 or another cloud provider. In hardware, they might choose the processor¹s clock speed or determine how much memory overhead would accommodate future upgrades.

In both cases, design is measured differently than product management and development. We teach that members of the product team should be measured on their effectiveness at bringing accurate market data into the business to feed better decision making. Meanwhile, development is often measured on a combination of scope, time and quality.

But for design, measurement needs to answer several core questions:

  • Does the design effectively solve the user¹s problem?
  • Does the design fit into the user’s daily life or workflow?
  • Does the design act in a way the user expects it to act?

The bottom line is: Design is a huge role, encompassing a wide variety of areas. It¹s very rare that one person is highly skilled at both front-end and back-end design.

In my experience, back-end design almost always reports to development because of the intertwining technical nature of the decisions these architects make every day.

Meanwhile, front-end design has migrated in the past decade, reporting to development, then to marketing, then to product management. It eventually became its own group in some companies, and is also sometimes a contracted resource that reports to the hiring party.

Like product management, there¹s a natural tension between front-end design and development (and marketing) teams. This tension arises from differing (sometimes competing) goals and measurements of success. Typically, this tension is a good thing, but when we shove front-end design under development or marketing, the tension resolves in favor of whoever owns that team. For instance, a development team who owns design and is measured on hitting the date will naturally pressure designers to create designs that achieve that goal‹not necessarily conducive to good designs for the user.

So who owns design? The designers, of course. And who owns the designers?
The goals of product management are highly aligned with design, so I can easily see reporting up the same structure. I can also see success as an independent part of the product team.

But wherever you place design in your organization, have an honest conversation about how designers are measured. If you measure design like development or marketing, the results will be suboptimal‹and understanding that is more important than where they sit.

Author
  • Paul Young

    Paul Young oversees the strategic development of Pragmatic Institute’s portfolio of products and leads the executive team in the evaluation of new product opportunities. He also manages the instructor team. Paul began his career as a software developer and has worked in startups and large companies across B2B and B2C industries, including telecommunications and networking, IT and professional services, consumer electronics and enterprise software. He has managed P&L lines for products with hundreds of millions in revenue, and faced difficult choices about which products in the portfolio to retain and which to kill. Reach him at [email protected].

Author:

Other Resources in this Series

Most Recent

Revenue retention
Article

Net Revenue Retention: A Critical Indicator of Business Health

Net revenue retention is maintaining and increasing income from existing customers over time. So it’s a critical metric that impacts the sustainability and scalability of any business
Article

Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd
Article

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...
Creating a product roadmap: what should you include
Article

A Guide to Product Roadmaps: How to Build One That Works

A product roadmap is a frequent request from the sales force and others in the company. ‘What’s coming in the next release and the ones after that?’ Long buying cycles common with strategic products often...
Dry erase board with product roadmap drawn on it
Article

How to Build a Brilliant Visual Product Roadmap

Building roadmaps is a crucial part of a product manager’s job. Yet most product managers still use outdated tools for roadmapping—Excel, PowerPoint, wikis, etc. The good news is that there’s a better way. Executives have...

OTHER ArticleS

Revenue retention
Article

Net Revenue Retention: A Critical Indicator of Business Health

Net revenue retention is maintaining and increasing income from existing customers over time. So it’s a critical metric that impacts the sustainability and scalability of any business
Article

Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

Subscribe

Subscribe