Full write-up at https://www.prodpad.com/blog/decisions-debt-and-other-dilemmas
Our world, as product managers, is filled with making decisions, and making decisions means making trade-offs. Trade-offs so often means taking on tech debt, design debt and other types of debt, which can be a dilemma for companies, especially if it stacks up too much. This presentation explores how to address the uncomfortable topic of working debt, and how to use it to your advantage when making trade-offs.
37. Support bears the burden
Better help docs are needed
Wasted time with manual processes
or shaky automations
App too hard to use?
Tech not up to scratch?
64. Step back,
look at the wider picture,
& use debt to your advantage
Don’t just make
product decisions
65. Take a pic of this slide!
Want to ditch deadlines? Here’s how to handle the objections:
bit.ly/ditch-timelines
www.mindtheproduct.com/free-your-product-roadmap-and-ditch-the-timeline
Have a more mature product portfolio? Strategies for staying lean:
bit.ly/growing-up-lean
www.mindtheproduct.com/growing-up-lean
Want today’s slides and notes?
bit.ly/decisions-debt
www.prodpad.com/blog/decisions-debt-and-other-dilemmas
Want to keep in touch?
linkedin.com/in/jannabastow
mindtheproduct.com/slack
twitter.com/simplybastow
janna@prodpad.com
Notes de l'éditeur
I used to be a product manager.
I used to ask all the usual questions
Like…
What problem are you trying to solve?
And..
How might we solve that,
or how might we discover more about that?
And
Have you tried turning it off
and back on again?
I’m a CEO now,
having stepped up
to build my own thing which turned into ProdPad,
I’m also one of the founders of Mind the Product,
and a trainer and a mentor and I’ll be around all day to answer questions,
or generally happy to chat about product with you if you reach out on Twitter, LinkedIn, or email.
I’ve also posted my slides and notes so you can have them for keepsies or sharing later.
These different roles have given me different lenses on the world.
Being a CEO gives me a particular lens that I obsess about….
Debt.
Debt is an uncomfortable topic.
No one likes talking about their financial failings.
It can break up families and friendships.
Likewise, debt in your working life can cause tension and storming,
breaking teams and builds.
And in your working life, debt can come in many forms.
But we’re going to talk about how we use it to our advantage.
Our world is filled with making decisions,
and making decisions means making trade-offs
Building a product is a multi-dimensional problem.
It can't be done without making trade-offs,
the same way you can't get through life without making trade-offs.
Most of us can’t get through life without going into some sort of debt.
Getting a mortgage, an education, a car,
all commonly require some sort of financial debt.
You could try to save up the cash ahead of time,
but you’d likely be dead before you saved enough.
You can imagine trying to build the perfect product,
allowing no debt before it goes out the door.
You’d be obsolete before it was launched.
You might be familiar with the iron triangle
of time, cost, scope, and quality.
For any one of these factors to give,
we’ve got to be willing to give on another front.
We rarely have spare budget or extra cash to play with,
so time or cost is often flexed in exchange for scope and quality.
This is exactly what we’re doing when we run experiments
using quick prototypes and MVPs;
trading off perfect quality or full scope to gain back a chunk of time and cost.
But that approach isn’t sustainable forever.
You know the saying: Good, fast, cheap; pick two.
If you always optimise for speed and short term cost savings,
you’ll never actually have a stable and usable product.
Making these trade-offs and taking on debt is okay and healthy,
if it's understood and managed.
It can also get out of hand.
Let’s talk about tech debt.
No one likes tech debt, but it's a reality of your product's life.
By tech debt, I mean the bugs or limitations built into your product's code,
or really, the cost of reworking existing parts of your product
that were built in a hasty or subpar way
instead of the full and ideal solution
you would have wanted.
Like financial debt, you might find that some tech debt is intentional.
After all, your team can't be expected to build the most perfect,
most scalable version of the product from day 1.
You might agree to take on tech debt as a trade-off,
so you can learn fast from an experiment.
This is fine, if the team knows what’s at stake,
and how the tech debt will be measured and managed.
Other tech debt is unintentional.
It comes about when you don't have these conversations with your team,
and there's not a shared understanding of how the product is meant to be built
or how the company wants to deal with tech debt as a whole.
Because, while intentional tech debt might come from smart trade-offs
that enable a team to run a mix of experiments and more robust product enhancements,
unintentional tech debt usually comes from beyond the tech team's control.
I blame deadlines.
Now, sometimes deadlines are necessary,
and I’m not saying that we should never work to them.
I AM saying that we should ditch the timeline roadmap.
Your bosses and your customers love this format of a roadmap, right?
It gives them so much certainty of what’s going to be done and when.
But it’s setting your team up for failure and it’s basically a tech debt collection pot.
See, if you deconstruct this format of roadmap,
you basically get a chart
that maps out ‘time’ versus ‘things to do’.
You have time on the x-axis,
creating this timeline.
And at first, it’s seems pretty harmless,
especially in the short term,
but the further out you plan,
and the more you put on there,
the harder it becomes to manage!
And because that timeline sits at the top,
always marching forward,
no matter what you put on the roadmap,
Everything includes a deadline
And this is where the problems start happening.
Try as we might to add enough buffer
and breathing room to our timelines,
when you’ve got that many things going on,
two things are bound to happen:
First of all, you might be familiar with Parkinson’s Law.
If not by name, at least by concept.
It’s the one that states that work expands
to fill the time given for that work.
So no matter how much buffer
you’re adding to your timelines,
you always seem to be cutting it close.
Scope creeps,
and other things cut in.
Which means that your team finds themselves
up against a deadline crunch
way more often than you’d like.
And you’re forced to make a trade-off.
You’re no longer making an informed decision
about a reduced scope or time limited experiment,
but instead,
making last minute adjustments to the plan
to take out features
or lob more resources at the work
to get the job done.
But the real damage is done underneath the surface,
where the product manager often doesn’t even realise…
Code that could have been
more elegant, readable and performant isn’t built,
and a more rushed version goes live instead.
Comments and documentation are left by the wayside.
Your release might look
like it meets all the requirements,
but underneath, it’s just that little bit subpar.
You’ve accrued some new tech debt.
Sometimes these deadlines come in wave after wave
as each sprint is marched out the door.
It causes team stress.
Developers ditch their jobs,
and then you’re left with a pile of junk for a codebase,
but there’s no one on the team who’s left to fix it, leaving you with a costly refactor every couple of years.
Refactors are the worst. But it turns out that you can mitigate this issue.
It wouldn't be a problem with better communication, and if there was a plan to get back to that project and fix it up.
But everyone knows that V2 is the biggest lie that your roadmap ever told
Instead of a timeline roadmap and a bunch of arbitrary deadlines,
give your developers an understanding of your company goals,include them in the spec’ing process early
so they can share in the understanding of what the outcome is meant to be,and give them the time and space to deliver code they’d actually be proud to support.
Our rubric here at ProdPad is
"build this as if you're the one
who's going to be training up a
junior developer on how to use
your code and docs in a couple years time".
It sometimes means a couple more days in delivery
to get the final output is up to scratch,
but the devs are as bought into the company goals as the next person,
and don’t get stuck in rabbit holes or lose focus.
We get a great mix of stable code and regular releases as a result.
Underpinning all of this, at its heart,
is a big element of trust in your development team.
It’s not just tech debt that a product manager needs to worry about.
Design debt is made up of the limitations that are built into the product
that aren't down to a bug or it not working as designed,
but rather the design not matching the actual user requirement down the line.
It can be found amongst the calls of "It's not a bug, it's a feature!"
But design debt is sometimes even more insidious than tech debt,
because you're less likely to have a plan for it.
Companies are more likely to have a plan for paying down tech debt,
like having bug crush weeks
or allotting a certain amount of time to refactoring technical work,
but we don't seem to have a collective vocabulary around the concept of design debt.
Like tech debt, design debt can stack up.
You can’t improve what you can’t measure,
so a good starting point is having a way
to measure and understand the design debt in your product.
With tech debt,
we’ve already got good vocabulary for this -
we separate out our functional bugs
from our new user stories, for example…
but where do things like usability ‘bugs’ sit?
Our Product Designer, Kav,
came up with a way of measuring design debt that I found really helpful.
He sets up a usability test that’s focused
on the core jobs we expect users to want to do.
Users are marked on their ability to complete the job
bright green if they completed the task without help,
light green or yellow if they struggled a little or a lot,
and a red mark if they couldn’t get the job done.
The changes over time gives guidance on where to focus
to pay down design debt and increase usability across the product.
Improvements can be visualised with each iteration.
As product people,
we want to be able to iterate and release quickly,
to experiment freely and learn as much as possible
in as short a time as possible.
An MVP experiment is really nothing more
than reducing scope in order to get something
in front of the market faster and cheaper.
Ideally, experiments are digested for their lessons,
and then put to bed.
But good experiments are still costly and time consuming to run,
let alone the cost of building stable new features,
and corners do tend to get cut.
We often end up with a product that’s
patched together out of past MVPs and experiments,
and is hardly a delight to anyone.
Using a design system can help here.
These are often thought of something fanciful,
the design team’s dream, but are rarely thought of as a priority.
But just as a stable codebase, steady releases
and proper tools are important in the tech team,
having a design system is an important ingredient
for a company that wants to get the best results.
A design system provides a baseline
so that experiments and new features can be
spun up with less of a trade-off on time,
and with less chance of incurring design debt.
If tech debt and design debt aren’t kept in check, they spill over.
Your company’s processes should help support
the offline parts of your product’s experience
But where you’ve got lots of tech and design debt accrued,
you’ll find that you end up relying on humans to make up the shortfall.
For example, if a section of your app is particularly unusable, your support team will be picking up the slack
and spending more time on inbound tickets.
They might need to write better help docs
to compensate for usability issues
that should have just been intuitive in the app itself.
You might find yourself with a bunch of
shaky automations and manual processes,
instead of solid tech holding your services together.
Sometimes unscalable processes are perfectly appropriate…
in fact, these are key to learning, just as any experimentation is. Depends on your stage of company and what your ultimate goals are.
But left untended, it can be costly.
It’s not uncommon for processes to be put in place and forgotten about.
Again, it’s important to measure.
We don’t often measure the Cost to Serve figures,
as in how much it’s costing a person to do a function,
rather than provide a more suitable tech solution.
Product decisions should be done
looking at these sorts of things holistically -
not just at user pains in the app,
but at costly business pains that might be hidden
behind the scenes in bloated processes.
And
Sometimes debt goes entirely unchecked at companies,
and this comes at a real cost.
Managing debt well seems to be
a bit of a mindset thing for companies -
some think holistically about the
state of their products and services and build for the long-term,
while others seem to really suffer from short-term-ism,
An attitude of collecting debt left, right and centerWith no concern for the racking up costs.
So what’s going on at these companies?
As with many things,
it comes down to incentives.
Companies, particularly large and public ones,
want to increase shareholder value.
CEOs are incentivised to show quarter-on-quarter,
steady growth.
If they don’t, they are turfed.
Management wants to show predictable growth,
for fear of spooking investors.
And the best route to predictability
is to break the business up
and look at it in smaller, more manageable chunks.
And this sort of makes sense too…
except what that basically leaves you with
is silos
Which leads us into dangerous territory,
where vanity metrics rule.
Division leads find themselves competing
to max their own proprietary metrics,
instead of collaborating for the good of the business.
Which leads to silo’d decisions.
They might sense for the bottom line in one division,
but are counter intuitive for the business as a whole.like letting one team stack up design debt
even though it’s jamming the support team full of queries.
Every silo is measured as either
a profit center or a cost center.
Management’s goal is to squeeze
just a little more revenue out of sales and marketing…
and to push down costs in support, tech, and operations.
And you know where product and innovation sits?
We’re seen as a cost center.
We’ve historically reported into a tech function
whose job it was to keep a close eye on costs...
Which basically gets us trapped in this old pattern
of writing finely detailed specs,
breaking them into points,
and being measured on ‘velocity’,
or how quickly your team can ‘burn down’
a stack of points.
This model might control costs,
but it optimises for building features,
not for solving problems.
It’s output focused
when it should be outcome focused.
All this pointsing
and burning down at high velocity
rarely leaves room for discovery,
and instead usually leads to team burnout
and all sorts of tech, design, and process debt.
So you end up with organisations
that are riddled with working debt
That are skipping discovery
and building the wrong thing
And setting themselves up to get disrupted
There’s a bigger cost than just what’s built or not.
There’s a cost to the cognitive dissonance
that your team feels when they know
they’re being dragged down by debt.
This cost accrues as your culture debt
It results in storming as well.
Remember I talked about trust and incentives earlier?
One of the biggest causes of tension in a team
looks exactly like this:
You’ve got someone on the tech side,
and someone on the business side,
and they end up in a fight over a deadline or a project.
They’re not fighting because of personal tensions
They’re disagreeing over the OUTCOME of the project,
because it’s asking them BOTH
to work COUNTER
to what they’ve been INCENTIVISED to do.
The developer is usually the one advocating for quality.
The business person wants it done on time.
They’re both being pressured to give a little,
or sometimes a lot,
depending on whether it’s an engineering-led organisation
or a sales-led one.
Oh, and the product manager is always STUCK in the middle
arbitrating the whole thing.
… … …
What’s missing is a shared vocabulary and TRUST,
where they can talk about their incentives honestly,
and talk about the trade-offs they ARE and AREN’T willing to make,
and how they impact the business.
Over the course of these conversations,
each GIVES a little,
and common ground is found,
and a compromise is delivered that works for both people
AND the business.
Like agreement on a time-limited experiment with
permission to go back and refactor afterwards.
Or perhaps an agreement to get the developer involved EARLIER
so that misunderstandings are avoided next time.
This is where cross team collaboration,
transparency, and psychological safety
come in to save the day.
Any company needs to make it a priority,
as in company-level objectives, to address debt,
and have measures in place
to understand and communicate debt,
as well as provide means for people
to easily spot and speak out
if they see debt being incurred without a cohesive plan.
Some of you might work for wonderful companies
that already have this sorted out.
Some of you are nodding along
and furiously taking notes.
Doubtless, I’ve just added a number of things
to your TODO list for monday and beyond,
and the day’s hardly begun.
Before we go,
I’m going to address a final type of debt
that you have direct control over…
Admin debt.
As product people, we’re knowledge workers.
We work with our minds and our sticky notes and our meetings.
Pretty much everyone we work with in our tech circles
are knowledge workers too -
coders are coding, marketers are marketing, sales people are selling.
We spend our time doing
what it says in our title and in our job description,
and yet there’s so much more to our work than that.
Admin debt is the cost
of all of those little non-work tasks that pile up -
like sorting through emails,
organizing files,
keeping apps and OS’s up to date,
transcribing notes into actionable tasks,
or whatever else keeps you busy
between the stuff you actually report in your daily standup.
To cope with admin debt,
treat yourself to tidy up time.
On our team, we’ve set it as a 2-hour block of time
at the end of each working week
that everyone in the company participates in.
It’s used for tidying up desks,
getting to inbox zero and setting filters so that we can stay there,
setting up automations to smooth out our workflows for the next week,
consolidating todo lists,
or whatever’s needed so that we can all have a relaxing weekend
and come back on Monday with fresh, creative minds.
Time paying down debt is always worth time spending.
Debt is a reality of our lives.
You won’t be able to build the best products
by avoiding debt altogether
And you won’t be able to build a
healthy business or mindset
by letting it stack up.
Often times,
something becomes a little less scary when you talk about it,
when you and those around you have a shared vocabulary for it,
when you have a way of measuring it and taking action on it.
I hope I’ve given you a few new ways to think about the work you do
and how decisions and debt interplay
and can in fact be used to your advantage,
when you step back and look at the bigger picture.
I may have also left you with questions,
as I know there’s so much more
to becoming outcome led,
ditching deadlines,
and making the best decisions as a product person.
You’re certainly in the right place to learn today, and I’ve included some links to some top resourcesthat will help you on your journey.
Thank you, amazing product people of Manchester!
I look forward to meeting many of you today. Enjoy the rest of your MTP Engage!