Let’s take a look at tools and techniques for product managers to help developers code faster.
When was the last time your team was moving slower than you would like? Product managers have two main jobs: to deliver value to the customer and to deliver that value as soon as possible.
Assuming you understand what’s valuable to your users and work on the highest-value items first, the next requirement is accelerating the release of those features.
Coordinating engineers and designers to deliver value swiftly can be daunting. Often, you, as a product manager, can feel powerless in many aspects of delivery.
There are a handful of things within your control, though; if you focus on these, you will see an immediate impact in delivering the most important features quickly.
Here are the most important things product managers can do to help their engineers deliver value quickly:
- Don’t just be clear. Be very clear.
- Make sure what’s in your head is in everyone’s head.
- Plan obsessively.
- Encourage devs to use AI tools that help them.
Let’s dive into these.
Look at the image below. What animal is this?
This is an elephant. If we’re judging just by the bones, you will get the broad strokes, but you would miss out on the most defining feature — the elephant’s trunk.
With any feature, we start with the bones, as the whole product falls apart without them. Just building the bones doesn’t lead to the feature as envisioned. If you stop at the bones, you may not deliver the features that can make a product feel special or unique.
This type of misalignment can be due to how you as the product manager describe the feature through product briefs and meetings.
Don’t stop at explaining the gist of a feature. Describe every possible aspect of it. Once your feature is complete, dogfood it until you are 100% confident it’s as it was first envisioned.
There is a fine line between clear and very clear. Always push to be very clear.
This line could be the difference between a defining feature and a flop.
Along the same lines as above, you must cultivate a common understanding with your team.
Get ideas out of your head. Talk through them. You have to get on the same page as your engineers. Never assume that an engineer is thinking the same thing as you.
Design plays a big role in this as once a design is on paper, less is left up to the rest of the team’s imagination. But many things — interactions, connections, etc. — may not come across from a Figma mockup.
In the book Sprint (audiobook) by Jake Knapp and John Zeratsky, they discuss the problem with abstract ideas:
Abstract ideas lack concrete detail, it’s easy for them to be undervalued (like your idea) or overvalued (like the boss’s idea).On Tuesday, we’re not asking you to sketch because we think it’s fun. We’re asking you to sketch because we’re convinced it’s the fastest and easiest way to transform abstract ideas into concrete solutions. Once your ideas become concrete, they can be critically and fairly evaluated by the rest of the team — without any sales pitch. And, perhaps most important of all, sketching allows every person to develop those concrete ideas while working alone.
Make sure there nothing is abstract when it comes to defining your product’s features. Take the time to ensure what’s in your head aligns with how your team is thinking about the product.
It’s easy to fall into the trap of setting a plan and feeling like you can or should just execute on it.
From the Nature of Software Development by Ron Jeffries:
It’s not good enough to plan just at the beginning. Because we’re focused on value, we need to plan all the time. The team should be working to a fixed cadence, often called iterations, or sprints, a couple of weeks long. Things go best if each feature, often called a story, takes only two or three days to do.
I don’t recommend working with larger stories and breaking them down into technical items, often called tasks. If we use tasks, the business-side people do not have a clear look at how things are going, and they often do not get a good sense of how to help until the end of the two-week sprint interval. Stick with stories: they work better all around.
Unfortunately, the role of PM requires constant re-assessment of one’s roadmap and priorities.
The book Product Roadmaps Relaunched goes so far as to have a disclaimer on any roadmap you present:
Most roadmaps contain some sort of caveat just to make it absolutely clear that anything in the roadmap is subject to change without notice. This protects you from accusations of broken promises; it also protects your customer by making it clear that change is possible, even likely.
While context switching can destroy a team’s productivity, not working on the most impactful feature can significantly limit a team’s impact.
A simple solution is to set up a time with your team leads every week before calibration or your weekly sync. Our team’s is called a prioritization station—call yours whatever you like.
- Are we working on the features that will add the most value for our users?
- Are there any new requests that have popped up in the past week that deserve to be prioritized now?
- Are we addressing any critical security or tech debt items?
- If something is being developed and a higher priority comes along, what is the productivity cost of context switching?
If you consistently address the above, you can be confident you’re working on the highest-value items.
AI will help engineers — so much so that developers are writing eulogoies for their craft:
Bodies of knowledge and skills that have traditionally taken lifetimes to master are being swallowed at a gulp. Coding has always felt to me like an endlessly deep and rich domain. Now I find myself wanting to write a eulogy for it.
(From James Somers’s “A Coder Considers the Waning Days of the Craft” for The New Yorker)
You should always encourage your team to use the tools that can help improve their work and their morale. While AI can help developers, there are a couple of key caveats.
- AI will help most with repetitive, easy tasks. It won’t help on the big challenges your team faces.
- AI will help junior engineers more than senior ones. Junior engineers have more to gain.
- This is a double-edged sword, though. AI may slow down the development of junior engineers.
Github ran several studies on the impact of its Github Copilot tool. Github Copilot helps developers by auto-completing code and turning natural language prompts into code.
When using Github Copilot, developers completed tasks in half the time. Not only were they more efficient, but they also felt more productive. This type of benefit may seem insignificant, but if it leads to better retention and morale, then it almost surpasses the efficiency benefits.
The above tools and techniques can help you drive impact faster by creating clarity and pushing for efficiency. Do you use any of the tactics above? Have you seen any of your actions deeply influence how quickly your team delivers value? Drop a line below!
And as always, thank you for reading!
