Product ?? Dev: Building trust

I do a lot of roadmap clinics with our ProdPad customers, and one last week illuminated a particular tension point that’s really common but not well understood:

Trust between product and development.

In this particular case, it was visible in two areas: 

Visibility and ownership of tickets in backlog

The product person I was speaking to was struggling with reconciling their process with a request from the Chief Technical Officer (the CTO). The CTO was suspicious over the team’s recent move to ProdPad, as they wanted to keep all of the tickets in one place: in the development backlog, which was Jira for this team. 

This doesn’t seem like an unreasonable request from the outset, but we dug into why it was causing stress and what problems it was causing for the team.

Now, there’s a reason so many product people hate Jira. It’s not a bad tool, per se.. it’s actually a brilliant tool when configured to do what it’s designed to do: It’s a development task tracking system. It’s good at managing a development backlog and helping a team organize who’s working on what, and how tickets are grouped and tackled as part of sprints, and delivered.

Where Jira falls over, is when it’s used for everything, from inception of ideas through to delivery and beyond. It quickly becomes overstuffed and stressful for the developers, who’ve got to contend with a task list longer than their arm (most of which isn’t defined and ready for dev anyways!), and it freaks out the rest of the team who are just wondering where their ideas keep disappearing to. 

Rather than stuffing all tickets in one big to-do pile, it’s healthier to think of your backlog in two parts:

Development backlog: These are your approved, ready-to-go tickets that have been prioritized and have enough information and context to them that a developer can more-or-less pick up a ticket and start working on it, and know that they are working on the right thing. It’ll include user stories or tickets related to new features or experiments, as well as bugs and other dev-ops tasks.

Product backlog: This is your larger, less defined backlog of things that you might do. Marty Cagan calls it an Opportunity Backlog. Think of it as a list of all the things you could do in order to solve problems for your business and your customers. It’ll include ideas for new features, experiments, assorted insights, and all sorts. Many of the ideas in your product backlog might be bad, or a bit meh.. and that’s okay! It’s the job of the product team to understand the problems they are trying to solve, and pick out the best opportunities to tackle with product discovery. 

Here’s why this separation is helpful and necessary:

• By ensuring that only approved tickets are in Jira, the development team can focus on working autonomously and efficiently. They aren’t constantly held up by trying to ascertain if they are working on the right thing, or hunt down more context for a ticket, as it should be at their fingertips. It also allows them to pick and choose how to group tickets in the best way, moving faster through the backlog and delivering in increments that make sense.
• When tickets are no longer buried in Jira, better product decisions are made. A healthy backlog should be visible to the whole team, not just the developers. A good product team should be prioritizing the problems to solve, and working with the experts around them (customers and team members in all areas of the business!) to understand how to tackle each challenge. After all, it’s not the job of the product person to have all the answers, and it does them no good to hide their work—the process in which problems are prioritized and experiments are devised—away in some tool that only a small portion of the team actually looks at. 

Going back to the original problem, I see this one of trust: The CTO didn’t trust the product team to manage the product backlog separately, and their instinct was to simply request it was kept behind the development team’s walls. By talking through the fears here, we were able to get to the heart of the matter, and show that a separate (but connected) backlog would give the developers and the rest of the team the visibility they need, while taking a lot of weight off of the developers and their sorely bloated instance of Jira. It was a win-win!

If you’re struggling with an overstuffed backlog, try here’s how ProdPad specifically solves that problem: https://hello.prodpad.com/problem-solved-stuffed-backlog 

Visibility of progress through development

The other problem in this team, again, a common one, came up later in the conversation. The product person asked me how they could go about tracking the progress of every ticket that development worked on.

While there are ways for a product person to get this close to development, I pointed out that it’s stretching the remit of the product person—we’re not meant to be delivery managers watching this closely!—and suggested that it might indicate a lack of trust from product to development. After all, trust goes both ways!

Here’s where the super-detailed ticket tracking leads us astray: 

???♀? You could try to track every last ticket through to completion, but because of the nature of development, there will always be variance. Sometimes new edge cases will be found, other times, shortcuts. Estimation is an art at best, and no one has it cracked.

?? There will always be tickets you don’t have eyes on. Not just user stories you didn’t think of, but also bugs, dev-ops tasks and whatever else the developers need to tick off in order to keep things moving on their side of things. 

?? You, as the product manager, don’t own 100% of what the developers work on. It might be 70%. Or 50%. Or less. The other time is tied up in other important work, but not necessarily product work. This is because development is more than building new features and experiments. There needs to be time for paying down tech debt, documentation, and a whole array of other development tasks.

?? By trying to track everything (whether this is yourself as a product manager, or because you’ve got a boss breathing down your neck asking for specifics on deliveries), you’re actually causing tension and a vicious cycle: 

• Development team adds buffer in order to make sure they don’t let you down on their estimates and that they have time for whatever new tickets or unknowns they might not have accounted for ?
• This leads to Parkinson’s Law, which states that “Work expands to fill the time given for that work”. Scope has a tendency to creep and work has a tendency to take longer than expected—always about as long as you estimated, even if you _really_ stretched your estimates! Your team is always up against a deadline crunch and things are still getting left out or misestimated, even with the buffers added ?
• Things take longer to develop, and the business perceives this as things moving slowly and starts to get jumpy and nervous, and so try to tighten their controls even further by poking holes in the estimates and constantly badgering for details on progress. This creates a Blame Culture, which is the opposite of psychological safety ?? ?
• Developers feel uncomfortable giving honest estimates and give even longer estimates—which results in this vicious cycle continuing! ?

There is a better way though, and I spoke to this team about the importance of trusting their development team and advocating for their processes. 

• Give development space to work on their own things. Chances are, you already have some format of this, in terms of a percent of time carved out for bug crushing or R&D time. Your dev team needs sufficient time to pay down tech debt, to manage code bases and libraries, to upkeep all sorts of hardware and software. Understand what they need, and advocate for, and help protect these sacred times. Understand that if a developer says something will take 8 hours, that’s not to be taken literally as one working day of just sitting there, but possibly several stints, chopped up in a way that makes sense for the humans involved in that team. If something has a bunch of dependencies you don’t understand, listen to the experts on the dev team rather than question every ticket or minute that’s spent in their domain. 
• Don’t work your developers to deadlines. Incessant and arbitrary deadlines are the source of tech debt, team stress, and often core to the reason developers end up quitting. Here at ProdPad, we don’t work to deadlines unless absolutely necessary. The rubric we work to is “Code as if you’re building for a junior developer you’ll be hiring and training on your code and docs in a couple years time”. We have a shared understanding of what ‘Done’ means and how/when to avoid rabbit holes, so we don’t get stuck with over- or under-engineering anything, and for the most part, we give that little bit of extra time to build for quality.
• The no-deadlines thing is massively helped if you can take stress off the release cycle. Oftentimes, things like continuous integration, continuous deployment, and better release practices, are thought of something fanciful and very much in the CTO’s domain—not something the rest of the team needs to worry about. But there are so many business benefits to faster, smoother releases, it’s a wonder the whole team doesn’t advocate for these! Faster releases means shorter feedback loops and faster learning… and it also means that your developers don’t have to stress about getting their code out in time for a specific release date. If they miss Tuesday’s release, for example, they can have it ready for Thursday, when they are sure their code is production ready. It takes the stress out of hitting deadlines, and instead allows the product and development team to work together on creating a steady stream of incremental value. 
• Focus your effort on prioritizing problems in your product backlog by understanding and communicating the problems to be solved, and highlighting the top candidates for experiments or potential solutions to those problems. Put those forward to the development backlog, and trust your development team to do their delivery thing! 

It was clear that the team I was speaking to had similar problems to many others that I’d encountered, and that the problems stemmed from slightly unstable trust in both directions. 

The tech team didn’t trust the product team to prioritize and set the right direction for the dev team without feeling cut off, and the product team didn’t trust the developers to be efficient without being able to see the work going through. 

Both needed to step back and understand the challenges that each team faces, and advocate for their processes and spaces to do so, in order for each to work effectively.

How about your own team? Have you seen issues like this, or other indications of lack of trust? How does it show itself in your team? Let me know in the comments ??