Decisions, Debt, and other Dilemmas
•
2 likes•1,525 views
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.
Recommended
More Related Content
More from Janna Bastow
More from Janna Bastow (10)
Recently uploaded
Recently uploaded (20)
Decisions, Debt, and other Dilemmas
- 1. Decisions, Debt, and other Dilemmas A story by @simplybastow
- 2. Want these slides and notes? www.prodpad.com/blog/decisions-debt-and-other-dilemmas bit.ly/decisions-debt Let’s chat linkedin.com/in/jannabastow mindtheproduct.com/slack twitter.com/simplybastow janna@prodpad.com Hi, I’m Janna Bastow!
- 3. Debt
- 4. Our world is filled with decisions
- 6. Debt is an enabler
- 8. Tech Debt
- 9. No one likes tech debt, but it’s a reality of life your product’s ^
- 11. Deadlines.
- 12. JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC
- 13. TIMETHINGSTODO
- 16. TIME Feature A Feature B Feature C THINGSTODO
- 17. TIME Feature A Feature B Feature C THINGSTODO
- 20. Parkinson’s Law
- 21. Parkinson’s Law Work e x p a n d s to fill the time allotted
- 22. Deadline c hcu !r n
- 23. You need to make lots of trade-offs Scope Quality Scope Quality
- 24. Team stress
- 25. The biggest lie in software is Phase 2. - Jeff Gothelf, Lean UX
- 26. Shared understanding of company goals Early collaboration in discovery phase Time and space to deliver great code
- 27. Build as if you’ll be training a junior in a couple years’ time.
- 28. Trust
- 29. Design Debt
- 30. It’s not a bug, it’s a feature!
- 32. Via Kav Webb @kylokav
- 33. Trade-offs for experimentation’s sake Quality Scope Quality Scope
- 34. Design system Better & faster product design decisions… Fewer trade-offs!
- 36. Process Debt
- 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?
- 40. Culture Debt
- 47. Profit Center Cost Center
- 48. Product management is a cost center
- 51. More debt throughout Building wrong thing Getting disrupted
- 55. Quality Scope
- 56. Quality Scope
- 59. Strategic objectives Holistic measures Safe communication
- 61. Admin Debt
- 63. Tidy up Time
- 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
Editor's Notes
- 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 center With 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 resources that 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!