How Product Can (and Can’t) Speed Up Development

Half of the calls I get from CEOs include requests for Product Management to boost productivity in Maker teams (aka Engineering aka Development aka R&D). To ship more stuff, faster. To hit more roadmap dates. To reduce some fictitious cost-per-feature financial goal. To get more for less.

This reflects confusion about what product managers do (and how we really add value), and often poor role definition where product managers are also project/program managers or engineering leads. It also signals a lack of trust between the executive team and the development organization: “how do I know I’m getting my money’s worth out of this mysterious process? How hard can it be to accurately forecast the next couple of quarters?” And reflecting frequent complaints from internal stakeholders that each of their demands/priorities isn’t getting enough attention. (Hint: the sum of those must-have-urgently items is 20x development throughput, so prioritization complaints never go away.)

But it’s not Product’s role to wring more code out of the maker team(developers + designers + CloudOps + test engineering + tech docs) or to restructure the development process. It is Product’s job to get the most customer value out of that process and to push for healthy product economics. Let’s unpack things that product managers shouldn’t do, can do to deliver more value, and recognition that our maker teams are craftspeople rather than robots.

Not Helpful/Not Our Role

Pushing more things onto the roadmap. We’ve known since the 1970’s that overloading a development team reduces their total output. On average, committing a team to 110% of their capacity means getting less IN TOTAL than 85% or 90% loading. With no slack, we can’t handle the inevitable surprises that (unsurprisingly) pop up in most sprints: system outages, hard-to-whack bugs, family emergencies, misbehaving partner APIs, customer demos, HR meetings about new benefits. When we’re overloaded, we cut corners and accumulate product debt.

Imposing development tools, processes, or coding standards. After three decades building B2B software, I have lots of opinions. But my product managers and I don’t get to veto the team’s choice of GitHub vs. GitLab vs. Bitbucket vs. SourceForge vs. CVS/SVN. If the team prefers spaces over tabs, that’s their call.
Reducing estimates. Estimation – rough-sizing stories or epics or tickets – is the team’s internal assessment of relative size and difficulty. The people doing the work are the best people to size the work. Product managers may have questions or suggestions… but maker teams quickly give up on estimating when we overrule them. I know I’m in deep water when I hear “just tell me how long the executives think this should take.”
Command-and-control specs. We hire the best developers and designers and test engineers, paying them handsomely. Maker teams (collectively) have more brainpower than product managers. So let’s not assume that we can write perfect stories or specs or requirements for them to implement exactly. We welcome questions, alternatives, and occasional heated arguments.

Ways To Boost Effective Throughput (Process View)

There are lots of ways that product managers can get more good stuff, as opposed to just more stuff. Looking at the process, this includes:

Ruthlessly prioritizing work, so we’re doing more of what’s important. Our company and customers have an infinite list of requests and a voracious appetite for new features, which can lead to chaos. So product managers need to be champions of the exclusive OR, sometimes packaged as “yes, of course we could do that if we postpone/cancel InitiativeA and CommitmentB and UpdateC and HotFixD.”
Slowing down interrupts just a little. If it’s not a P1 system down, then we don’t need to interrupt the team this very minute to size some new thing. Most emergencies disappear on their own a day later. Batch up interesting requests to run past the team every other week.
Clearly, frequently communicating goals and strategy. When our team understands the context of a problem and how users operate our software, they are empowered to imagine alternate solutions. Some will be better or faster or have a bigger impact on KPIs. Rather than command-and-control, good product managers want the best answers. Humbly, you can ask “if that’s what we want to accomplish, what have I missed? How else could we approach it?”

Forcing a little slack in the plan. Most makers are optimists, and schedules usually run late. Systems crash, partners change APIs, security holes are discovered, insidious bugs evade fixing, we learn what happens when AWS East goes offline. (Like every episode of every home improvement show, we discover mold in the basement or raccoons in the attic and have to adjust.)

Collaboratively defining DONE. Makers and product managers should agree on a general definition of done. That might include release notes, automated testing, pricing, performance benchmarks, and a training session for the Support team. Doing this once, thoughtfully, saves dozens of arguments about whether we can toss untested software to paying customers.
Don’t prioritize everything. Sometimes the go-to-market wants us to force-rank the top 300+ backlog items to help them focus on what might be easiest. But that’s a complete waste of time. Ron Lichty and I recommend estimating a quarter’s-worth of backlog and prioritizing the next 2-3 sprints. We’ll end up reshuffling much of what’s beyond that.
Funnel development requests into a single system. Support is using ZenDesk, and assigning tickets to Engineering. Sales is on SalesForce, and assigning tickets to Engineering. Marketing is building Powerpoints of potential new products, and sending decks to Engineering. Research has a UserVoice page for voting up backlog items. Product is on productboard or Aha! or Pendo or Roadmunk or whatever, and synching requests into Jira. We can’t expect our maker team to focus on what’s most important if product management isn’t consolidating input and reducing the noise.
Watching for gold plating and over-investment. Which capabilities are core and will drive next year’s growth? (So we must deliver something great, with tons of automated testing and UX validation.) Which are check-box items that few customers will use? (We can do less, stub out complexities, monitor for live usage, not commit to v2 and v3.) Without clear product direction, everything has to be perfect.
Politely but relentlessly asking about end customer value in big architectural work. Every re-implementation I’ve ever worked on has run very late, and most have failed. Is there an incremental or lower-risk approach? An 80/20 with most of the value?

Champion The Human Needs Of The Team (People View)

Our makers don’t typically report up through product management: they are our peers, not our underlings. But we have an important role in keeping them motivated, happy, engaged, productive. In reducing staff churn.

It’s easy to think of development as a series of well-defined generic steps: follow the recipe and we’ll get products. Ceremony X, template Y, scrum this, Kanban that. (No SAFe, please!) But building software isn’t at all like building fences or digging ditches. It’s a complex, creative team sport played by some of the smartest people on the planet. And great maker teams are mission-driven: if we can pull them in, give them a visceral deep understanding of what our end users do (and what frustrates or blocks users), we nurture a real love for the folks who use our apps. So carefully connecting developers and designers directly to actual user experiences clarifies their thinking and also boosts their enthusiasm. Emotionally committed teams can deliver twice the real value of paint-by-number/do-just-what-the-book-says/product-has-all-of-the-answers passivity.

Ways to encourage the team cohesion and passion for users:

Tie team outputs to customer/company outcomes. When we’ve shipped a new feature that’s helping close more deals, pass the credit through. When we fix a bug that dramatically reduces incoming support tickets, get the Support team to thank us. When we have a good quarter, find ways to share the win. When we collectively make the world better and real customers applaud, shout “our team is splendiferous” from the corporate rooftops.

Merchandize the good work of our teams. Go-to-market groups rarely know the names of makers, and often don’t know what they really do. And our teams desperately want to feel needed and appreciated. So make opportunities for the makers themselves to demo work to rest of company. Thank them by name in executive meetings. Endlessly translate “what we shipped” into “why this will have us make money” and “why users will cheer about that” and “how Engineering’s great work will frustrate our competitors.”
Handle or escalate issues that are out of scope for makers. I try to join team retrospectives when I can, not to fix their processes but to catch issues that they can’t fix themselves. Having trouble getting Finance to sign off on a new code check-in tool? Walk me through the logic, and I can attach some pseudo-ROI and lobby for approval. Whole teams spending hours in big unproductive meetings? We can advocate for tighter agendas or smaller invite lists where that makes sense.
Push back HARD against individual corporate reward systems; push instead for team rewards and goals. Software development is a team sport, which is the opposite of corporate sales reward systems. Fight force-ranked individual ratings within teams. Find ways to applaud the newest or youngest or least-similar alongside architects and tech leads. Organize a remote pizza party.
Build goodwill across departments. When sales/marketing teams talk down makers (as they often do), be their ally and defender. Likewise, when dev teams minimize the challenge of selling or marketing or raising capital, share some of the challenges. We mostly don’t want our developers to envy Marketing, but some respect reduces friction. Increases joy. Can’t we all just get along?

There are tons of jobs at other companies, including our competitors. Product has a hand in keeping our team happy, focused, productive, cohesive so they are less likely to take that next recruiting call.

Sound Byte

Product managers aren’t responsible for making development run faster. We are responsible for getting the most value out of their efforts. For unblocking them when they are stuck. And for engaging their enthusiasm.