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: The product team reviews the features the sales team is requesting. Product managers decide which requirements go into the next release. The sales team reviews the features and approves the product backlog. Requirements are prioritized based on what will close the biggest deals. Engineering starts implementing the features. Sales declare that requirements change to help close new deals. 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 Want to learn how to become the successful leader your team needs? to learn how. Sign up for my newsletter 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 a problem gets solved than its solution. how 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 to be a software engineer at these companies. great 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 what the team has built. These companies prioritize solving problems that help the most people. User experience trumps the needs of Sales and Engineering. love 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 that people just accept. to determine who owns the company roadmap. too many meetings You need to ask the right questions 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 , you’ll figure out the company’s roadmap culture. who makes decisions 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 or . LinkedIn Twitter Want to learn how to become the successful leader your team needs? to learn how. Sign up for my newsletter Also Published Here

Apple

Asana

Facebook

Funding

Google

Intel

Lockheed Martin

Microsoft

Twitter

When Over-Engineering Is A Good Idea

Writing an Annual Performance Review that Inspires Employees

Become the successful leader your team needs.

Tip a coffee and support Build the Stage

2021 - HackerNoon Contributor of the Year - TEAMWORK

2021 - HackerNoon Contributor of the Year - ENGINEERING-MANAGEMENT

Nominated for 2022 - All About Teamwork

Nominated for 2022 - HackerNoon Contributor of the Year - Engineering Management

Nominated for 2022 - HackerNoon Contributor of the Year - Hacking

Nominated for 2022 - HackerNoon Contributor of the Year - Management

Nominated for 2022 - HackerNoon Contributor of the Year - Project Management

Nominated for 2022 - HackerNoon Contributor of the Year - Management And Leadership

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Who Owns Your Company Roadmap?

Who Owns Your Company Roadmap?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Hacking Quarterly Performance Reviews

10 Online Free Courses That Can Help to Learn Agile Development

22 Alternatives to Trello for Simple Project Management

32 Project Management Tools: An Ultimate, Unbiased List

5 Proven Ways To Speed Up Digital Product Development

Hacking Quarterly Performance Reviews

10 Online Free Courses That Can Help to Learn Agile Development

22 Alternatives to Trello for Simple Project Management

32 Project Management Tools: An Ultimate, Unbiased List

5 Proven Ways To Speed Up Digital Product Development

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps