Eyes on the Prize - Keeping your Developers Focused on Outcomes
As a PM with a dedicated engineering team, I want to keep everyone focused on solving the right problems, so that we can build incredible products
EPIC: Mastering Product Management
Exciting times here at the Pivot to Product Substack! We’ve officially surpassed 200 subscribers 🥳. We have (some) traction towards product-market fit, and I couldn’t happier. I appreciate you - consumers of my content - and I aim to continue to bring value, wherever the Substack may go!
Now with a legitimate cohort of paid subscribers, I’m officially opening the door for article requests from paid subscribers. As I inch closer to completing the “Breaking into Product” series, paid posts more and more will shift to tactical execution of product work.
How to request? Make a comment on any article, or reply back to the email delivered.
To my pleasant surprise, I’ve been receiving requests from people working on newer projects before a formal “Product” org has been established - people on their software development hustle. The jungle’s own BowtiedBernard has been working on some cutting-edge tech Web3 tech.
Bernard reached out with some specific questions on how to keep the dev team focused on much-needed priorities as the company scales up. The conversation opened the question:
How can we keep a development team focused and prioritize the most important work deliver?
As an engineering team hits a critical mass of developers, the adoption of traditional product management practices becomes essential. Think when you start splitting your engineering org into multiple teams - there will be dependencies to map and parallel tracking of work. Perhaps your company wants to take investors who demand a certain level of maturity.
Eventually, we all have to grow up.
How Engineers Lose the Plot
As a PM who worked with some truly brilliant engineers1, I view my role as unearthing the biggest problems our users are trying to address with our tools. Then - I point our dev teams in that direction with a hellacious focus on outcomes. We should not just be an assembly line of marking tickets as dev complete - we need to be working with a specific purpose.
I often think of the following quote.
Engineers like to solve problems. If there are no problems handily available, they will create their own problems.
-Scott Adams
I view this as a simplification of a phenomenon I’ve observed. If there are no clear problems that need to be worked on, developers will start to tinker, and optimize parts of the code base that, while technically superior, may not result in anything meaningfully new to the end users & company as a whole.
The Solution to this phenomenon - a hellacious focus on meaningful outcomes.
Keep reading with a 7-day free trial
Subscribe to Pivot 2 Product to keep reading this post and get 7 days of free access to the full post archives.