Who Owns Your Company Roadmap?

Prioritizing the company roadmap was a challenge in my first engineering job. My team was hungry to create products that delighted people. We had the talent to build software as charming as Github, Asana, and others. There was only one problem.

The company didn’t care about the users.

What mattered was making a sale.

The sales team focused on the people signing the checks. They wanted to fill every item on the requirements list. Closing the large deals is what mattered.

My team couldn’t overcome the company’s economics. Sale requirements dominated our product roadmap.

Understanding how the business works is a core to prioritizing roadmaps. Over the last decade, I’ve found that one of three teams owns the product backlog:

• Sales
• Engineering
• Product

So how do each of these teams create a roadmap?

Read on to learn the answer. I’ll even share how I determine a company’s roadmap culture.

How do Sales Prioritize the Company Roadmap?

When sales own the company roadmap, closing the next deal is what matters. Stories of Sales-people promising unplanned features come from these places.

From my experience, sales-driven roadmaps are created by:

1. The product team reviews the features the sales team is requesting. Product managers decide which requirements go into the next release.
2. The sales team reviews the features and approves the product backlog. Requirements are prioritized based on what will close the biggest deals.
3. Engineering starts implementing the features.
4. Sales declare that requirements change to help close new deals.
5. The team works toward deadlines written in contracts.

Sale-driven companies are great for projects that get defined up-front. Consultancies come to mind here. Consultancies define the project requirements before a contract is signed. When requirements change, the costs get added to the final bill.

Sales-driven companies are not great for products. Enterprise customers often ask for one-off features. These requests incentivize the Sales team to change the company roadmap. Products deteriorate as more specialized settings get added.

Examples of Sales-driven Companies

• IBM
• Microsoft (during the Steve Ballmer years)
• Software Consultancies

How does Engineering Prioritize the Company Roadmap?

Engineering-driven cultures can be summed up as: “If you build it, they will come.” Engineering companies care more about how a problem gets solved than its solution.

Teams will focus on following best practices, scaling systems, and selecting the perfect tools for the job. Executives will understand what the teams are building. Experimentation is encouraged.

It’s great to be a software engineer at these companies.

Product backlogs are prioritized based on the best solution for a problem. Delays can occur whenever someone finds an edge case. Addressing tech debt takes priority over shipping.

What’s the problem with these organizations? Releasing features.

I’ve found that Engineering-drive companies are great for technically deep industries. Research start-ups and defense contractors come to mind here. These companies have a lot of funding to solve hard problems. It’s normal to invest years into a solution before making a sale.

Examples of Engineering-driven Companies

• Google
• Lockheed Martin
• Intel

How does Product Prioritize the Company Roadmap?

A Product-driven company wants to make the best product in the market. Product companies want users to love what the team has built. These companies prioritize solving problems that help the most people. User experience trumps the needs of Sales and Engineering.

At Product companies, people need to be thoughtful about solutions. Product Managers don’t take a problem at face value. They work to understand the context of a customer’s feedback. Product Managers figure out the job to be done with each feature.

This environment is challenging for people who hunger for short-term results or high-quality systems. It’s normal for product companies to pass on large customers. They don’t want to compromise the immediate roadmap to close these deals.

Product companies also accept software with “rough” implementations. If the code is good enough to solve the user’s problem, that’s fine. In my experience, software systems will have a mixture of quality. Some systems will have a robust design. Other code paths will be full of spaghetti code. What matters is a working feature that can improve over the perfect code.

It’s a practical approach to writing software.

Examples of Product-driven Companies

• Apple
• Facebook
• Sprout Social (my current employer)

How can I figure out who owns the product backlog?

It’s hard to figure out who owns the product backlog. Start-ups are still defining their culture. Large companies have too many meetings that people just accept. You need to ask the right questions to determine who owns the company roadmap.

Here are the questions I ask to find the owner of the product backlog:

• How does the company make money and sell its products?
• What is the CEO’s background? What are the founders’ backgrounds?
• How does the company prioritize its feature roadmap?
• What qualities represent high performers at this company?

These questions look at how the company works. The business’s economics drives most decisions. Decisions are influenced by the people at the top of the company and the processes they’ve created. By learning these fundamentals and who makes decisions, you’ll figure out the company’s roadmap culture.

Conclusion

Understanding who owns your company’s product backlog impacts your career. The people that drive the company roadmap will affect the projects you work on. For managers, you need to understand these politics so you can advocate for your projects.

Which team owns the company roadmap at your job? What companies should I refer to as examples for one of the described approaches? Let me know on LinkedIn or Twitter.

Also Published Here