Introduction: What You’ll Learn
This simulation helps you practice advocating for technical debt cleanup with a Product Manager. Your goal is to effectively communicate why refactoring is beneficial and secure their buy-in, all while keeping ongoing feature development on track.
You’ll practice:
- Explaining technical debt in everyday terms
- Highlighting the long-term benefits of refactoring
- Balancing technical needs with product priorities
- Building consensus using data and real-world examples
Step-by-Step Simulation
Scene 1: Setting Up the Conversation
You (Developer): "Hey Jamie, do you have a few minutes to chat about some tech improvements we’re considering?"
Jamie (Product Manager): "Sure thing! What’s up?"
You: "We’ve identified some areas in our code that could really use some refactoring. I’d love to explain how a bit of investment now can pay off significantly down the road."
Scene 2: Presenting the Case
You: "Right now, our technical debt is causing a few headaches. For instance, our build times have crept up by 20%, and new folks are finding it tough to get up to speed because the code’s a bit tangled."
Jamie: "How does this affect what we’re trying to achieve with the product?"
You: "Longer build times mean slower feature releases, and onboarding struggles slow us down further. By tackling this, we can speed up development and deliver features more reliably."
Jamie: "How much time are we talking about here?"
You: "I’m thinking we dedicate around 10-15% of our sprint capacity over the next few cycles. This way, we can address the most pressing issues without stalling new features."
Scene 3: Addressing Concerns
Jamie: "I get the need, but we’ve got some big features on the roadmap. How do we juggle both?"
You: "We can focus on refactoring tasks that align with upcoming features. For example, cleaning up the authentication code goes hand-in-hand with the new login features we’re planning. It’s about minimizing disruptions while boosting stability and performance."
Jamie: "Can you give me examples where this has worked well?"
You: "Absolutely. In a previous project, we saw a 30% drop in bug reports and faster load times after a similar refactoring effort. It really improved the user experience."
Scene 4: Gaining Buy-In
You: "How about we try this as a pilot? We start small, see what impact it has, and adjust as needed."
Jamie: "That sounds fair. I’ll need to see a plan with expected outcomes."
You: "I’ll put together a proposal outlining timelines, metrics, and expected benefits. Can we plan to review it together next week?"
Jamie: "Sounds good. Thanks for being proactive about this."
Mini Roleplay Challenges
Challenge 1: Jamie is worried about missing feature release dates.
- Best Response: “By tying refactoring to feature work, we can stay on schedule while improving efficiency.”
Challenge 2: Jamie asks for a quick explanation of technical debt.
- Best Response: “Think of technical debt as cutting corners to hit deadlines, which can slow us down later.”
Challenge 3: Jamie is skeptical about the benefits.
- Best Response: “I can share data from past projects showing how refactoring led to quicker releases and fewer bugs.”
Optional Curveball Mode
- Jamie shifts focus to a new urgent feature.
- Another stakeholder enters with different priorities.
- The discussion veers off into unrelated technical topics.
Practice keeping the conversation on track and focused on the refactoring proposal.
Reflection Checklist
Communication
- Did I explain the impact of technical debt clearly?
- Did I connect technical improvements to product goals?
Persuasion
- Did I use compelling data or examples?
- Did I address concerns without dismissing them?
Outcome Alignment
- Did we agree on a trial period or next steps?
- Did I make sure Jamie felt heard and involved?
Common Mistakes to Avoid
- Using too much technical jargon
- Not linking technical debt to product outcomes
- Overpromising quick results
- Failing to bring data or examples to support your case