Understand the benefits of understanding your product debt in relation to your overall product investment portfolio. We are all familiar with the impact of technical debt, but how often do you document and engage with the product equivalent? Product debt happens when you push a release out with a less than idea workflow; when the minimum in minimum viable product was minuscule; and when the technical investments impact the ability for the product to iterate. You’ll leave with a framework for evaluating your potential investments, and better equipped to communicate the risks of “skipping” activities like research, user testing, and product discovery.
Hear from Devbridge Director of Product Design, Chris Wilknson.
Watch the talk:
Transcript:
Hey, my name is Chris Wilkinson. I'm the director of product design for Devbridge. Today, going to talk a little bit about product debt. Let's dive into what that means. Product debt is the value that you borrow from your users in order to ship a product a little bit faster, and probably thinking to yourself that you've heard a term like this before, and it's because you have. It goes by other names: conceptual debt, design debt, user experience, any kind of debt that you might talk about, but really, it all boils down to this: we'll get to it next release.
Now, many of you might not know where this term comes from. This fine gentleman, Ward Cunningham, best known as the person behind the Wiki, which gave us later Wikipedia. He coined this term to say product debt is really what happens when you build to less than your full understanding of something in order to get something out the door, and it incurs a debt that you have to pay down, kind of like you're paying down a loan. If you think about it, it's any amount of extra work that you create for yourself by maybe not taking the best path at the beginning. It's also known by this phrase by the great American philosopher Wimpy, "I'll gladly pay you Tuesday for a hamburger today." All debts come due, and in product delivery, it's important that we're intentional and understand the debts that we're incurring.
What are the factors that play into this? Well, the conversation usually starts like this. You incur a little bit of debt so that you can get a little bit more speed in your releases. That speed comes with the burden of having not executed to your fullest understanding. Now that you have that burden, you're going to sacrifice some of your agility, your ability to respond to the market and to change your direction. You're a little bit more fixed. You're a little bit less flexible. You're a little bit less able to respond. To recapture some of that agility, you say, "You know what? Let's go into a little bit more debt so we can get some more speed," got that burden again at the cost of your agility, and so you go into more debt. Which, of course, regains a little bit of speed for even more burden, sacrifice even more agility, which then gives you even more debt.
How do you break out of this vicious cycle? Now, if you're hearing me talk through this and this sounds familiar to you, don't feel too bad, because the year this phrase and this idea was coined was the same year that this fine film won best picture, 1992's Aladdin. Here we are many years later, still having the same conversation. Why is that? Well, I think it's because there are two common myths that kind of perpetuate the scenario, two common organizational challenges that find us in this position. Right? First is MVPs just have debt. You need to ship to iterate. It's the idea that it's just a natural part of the process. While it is true that you can naturally incur it, it's also something that can sneak up on you later, and we'll talk about different kinds of debts that sneak up on you in a minute. Product and tech debt are inherent to what we do. We agreed to the functionality, so we just have to do it.
All of this combines together to create something that you can kind of think of as a subprime MVP. It's that minimum viable product where you never can reclaim the investment that you make, because you take shortcut after shortcut in order to get it out the door. How do you avoid doing this? Well, first is to take some advice from the real estate world, and not to let the real estate agent tell you how much house you can afford. But, it's also to be aware of two of the main sources of product debt. Let's talk about what those are. Now, it doesn't require somebody to really do a lot of analytical thinking anymore, to think about the best way to balance a team to start work. At Devbridge, we kind of articulate this in a pretty simple way. We have a product team that's made up of product management, software engineering, and product design. Those teams work together in a build, measure, learn loop to collaborate and create the best outcomes for the product that they're building for our customers.
Now, what I've seen a lot of organizations start with is something that looks more like this. The patented build, build, build loop. You see, first you build by build, build, building, and then you build by build, build, build, build, building. After you build, you build, build, build, build, build, and then you can build, build, build, build, build again. This constant churn of focusing on building the new, rather than building the right kind of product, is what causes teams to be hindered by their own progress over time. Sacrifices are made that then weigh teams down and prevent them from realizing the full value of the product that they're building.
One thing to look out for, feature factories. This probably sounds familiar to a lot of folks. You start at the land of the meetings, you go through the stuff to build the riser, the UX unicorn sprinkles its magic UX dust, and then the genius builders finish the product as the end of quarter machine rushes things through. If you're identifying this sounds a lot like the way that you're building products today, you're likely predisposed to incurring a lot of product debt.
The other thing to be aware of is a phenomenon called Conway's law, which dictates that organizational structure influences the organization of the products that you built. In other words, your product is a reflection of the organization that builds it. Here's six examples of organizations that might be familiar to you, and some nice examples of how they might influence each other. Now, I think since this graphic was originally made, I think there have been some improvements in the way that Microsoft's org structure is going, but if you're seeing these and you're laughing a little bit to yourself, it's probably because it feels a little bit true. Right? Conway's law is defined as any organization that designs a system will replicate their organization's design in that system. This is a culmination of a PhD level research effort in the same year that this film, A Man For All Seasons, won the Academy Award for best picture, 1962. If you haven't seen this classic of cinema, you got to put it on your watch list.
Now, the second challenge is a misinterpretation of what it means to do iterative delivery. I've used this graphic myself before, where you talk about what it means to iteratively arrive at an MVP. In waterfall, or even in feature factory kind of mindsets, you might have a wheel that becomes a chassis that has a body that becomes a car, and you're really not happy until the car is finished. We've talked about in the software world about starting with a skateboard and it becomes a scooter, starting with a bike and it becomes a motorcycle, and that motorcycle evolves to a car and someone's really happy and they're really excited.
But, I want you to just picture for a moment, what would that actually look like? If I had to turn a skateboard into a scooter, well, that's not too hard. Just get a pipe or something in the handle and stick it at the end of the skateboard and I'm doing okay. The skateboard to the bicycle, could maybe reuse the skateboard as maybe part of the seat. The wheels aren't really going to help me anymore. The handle, I guess, and the bar could be part of the frame, but I'm really going to build everything else after that. Now, if I want to turn a bicycle into a motorcycle, well, that's not too hard either. Sort of get an engine on there, but it's not really a motorcycle, it's just a motorized bike, so I'll probably have to rebuild most of it then, too. I'll let you try to figure out how you're going to turn a motorcycle into a car.
Now, why is this challenging? Well, when we present this as a metaphor for how to build products, I think we're setting ourselves up for challenging conversations in the future, because the mental model that people have is that you can go from a skateboard to a car, even though there is a great deal of technical challenges in going from a skateboard to a car. By the way, if we're having a conversation about having to turn a skateboard into a car, we're not answering the real question, which is how to solve the problem of transportation. I think this is a really, really important thing to call out, to avoid incurring product debt as you deliver any sort of digital product, which is to understand the problem space, you need to determine the metrics for success, and then build towards that solution.
Iterating towards a solution within the problem space of transportation allows you to incorporate things like, maybe, public transportation into the equation. That means that you're fine with just having a skateboard, and here in Chicago, the CTA. That also being said, if you really think through the problem space, you can come up with fun solutions like this fine concept vehicle that has a skateboard stored under the trunk, and this is pretty cool. But, you don't arrive at a transportation solution like this by trying to turn the skateboard into the car. You find the way to pair the skateboard with the car, allowing each of them to deliver their independent value.
Now, talking about the challenge of product debt, you have to assess where you are. If this hasn't been a regular conversation about the way that you build and deliver product, then you need to conduct an audit. Now, this can be kind of scary, because people really don't want to take the blame for the debt that's been incurred. This is where the prime directive for an agile retrospective comes into play. It says in part that I understand and firmly believe that everyone did the best job that they could with the information that they had at the time. By starting with this kind of a mindset, you can have an open conversation where you talk about your product debt objectively as a team, and talk about ways to overcome it, rather than focusing on which role incurred it and which one didn't. The reality is, if you have product debt, you have incurred it as a team, but more importantly, you've incurred it as an organization and as a company. It is something that you need to understand and you need to pay down.
Now, not all debt is created equal. Let's talk about how to model this debt. Debt's going to sort of fall on the spectrum here. You're going to have things that you deliberately did to incur debt, that's okay, and things that are inadvertent, a little bit worrying. Things that are prudent, so things that were the right thing to do, and things that were reckless, and then there's always a couple of reckless decisions that get made along the way in exchange for time or value. Right? What do these actually mean?
Well, one group is the things that we said we need to ship now and deal with the consequences later. This is the most common and the easiest to resolve form of debt. The next is, we don't have time to intentionally design the solution. Okay. What does that time actually mean? Are you responding to an actual date on a calendar, or are you responding to the idea of a date in the future? How did you get in this position, and what did you give up by not giving yourself the time and the space to intentionally understand the problem? The kind that is the most self-reflective, shall we say, is that we've learned something that tells us that now we know the right way to do it. We didn't know before, but we know now, and this is how it should have been the whole time. That's the most genuine and honest kind of debt to incur, and it is great when you find it.
Finally, the most tragic of the debts. What do you mean there's a fourth location for the master data? We had the whole API system set up. We had the architecture and the framework figured out. What do you mean there's a second environment? What do you mean there's an extra approval? What do you mean legal says we can't do this? These are the kinds of debts that you incur by not having the right kinds of conversations upfront, and things surprise you as you get close to the finish line. Debt in this quadrant tends to be the kind that ends up pushing back deadlines, pushing back shipping dates, and losing value for the organization because the right conversations didn't happen upfront.
Let's double down on understanding what it means to go into debt, and how we overcome it. I think a key of this, this is a Barry O'Reilly quote, the author of a book called Unlearned, which talks about not letting future success, or future opportunity be overly influenced by past success. In it, he talks about how we need to understand how customers, how people are going to interact with something. I think that we traditionally say we can understand that through going through intentional phases of development. We bring in the customer by having an analysis phase, there's some sort of ready phase on a Kanban board or on an agile board or Jira board, some sort of in-dev, some tests and some acceptance, and these sort of phases happen. Right? We all agree that if we go through this and we go through an agile mindset and are customer focused, we can capture all this.
I'm going to propose that we're a little bit bold here, and we experiment a little bit with this model. At Devbridge, we leverage a dual track prioritization methodology, and it allows you to take in the business considerations and the engineering considerations, each prioritized against their own constraints. In other words, you have a product backlog and a development backlog. In the product backlog, you're gathering the business questions. You are going out and researching answers to those questions. You're executing a plan to address that resolution, that solution through the product. You're creating synthesis that the business can consume. Not a giant readout report, but something very, very concise for an executive audience. Then, you take that outcome to influence your prioritization of what features to build next. Then you execute, as you would normally, having stories ready to go for an engineering team to build.
Now, all this is great, but I find an area where product debt starts to fall down and managing starts to fall down is around communication. That piece usually ends up looking something like this, someone where their frustrations with the product are outweighing the actual execution of the actual value that it could possibly bring. The way that you avoid this is through metrics. Right? Specific, measurable, achievable things, and understanding those throughout a product delivery life cycle.
I think a lot of folks tend to really focus on that development piece, which is good, and they don't give the time for upfront discovery, but really that means upfront understanding of the problem space and of the solution. They don't take time to measure and learn. But, really, that sounds kind of silly. Right? How silly would it feel if we just skipped this middle area and I never talked about that? You need that full cycle of delivery in order to have a valuable product. You need to understand what you're building and why, and why you're taking different prioritizations or different shortcuts at every step along the way, or it's going to sneak up on you at the end.
Now, I want to talk a little bit about how you can play this out for yourself in a case study. We did an engagement for a medical company. They specialized in handful of operational considerations in the medical space, and they needed a HIPAA compliant chat application to help them run their business, and no one ever really needs chat as a business function. Right? Chat's kind of a tool to get an outcome. What we did is we started with a service blueprint, and a service blueprint allows you to map out all of the participants and all the actions those participants take in a system. We took the pain points of that service blueprint, and we combined that with the business's desire to build a product, and identified where we should start.
We built a product over three months, and then tracked from there on the adoption metrics and the success the product had, through key things like how many people are using it on a daily basis, how many people are weekly involved, how many messages are sent. This particular chat app was solving the problem of staffing emergency rooms. Then, how many shifts are filled? That's a real bottom-line indicator, of how many shifts get filled. Well, that's an ER staff, those are lives saved. That's a good thing, and it's quantifiable. Is this chat app the most efficient way to address that? Through metrics be able to show that there was value in continuing the investment.
Starting with a mobile application for Android and iOS, building out additional chat functionality, and eventually an admin portal to manage sort of the overall view, we're able to show that there was adoption and use. Then, through those delivery metrics, we were able to show the need for re-investment. There was an upfront investment for an initial phase, value was demonstrated, and then the product was invested in again and again and again, bi-weekly releases. People engaged with it, taking in those new metrics, and then understanding where to go from there.
How do you go forward? Well, in the words of Ward Cunningham, the whole debt metaphor really depends on your level of understanding, and can you set yourself up to refactor and integrate new learnings. The way that you best set that up is by giving yourself the time and the space to understand the problem before you execute. And, when you do incur debt, being honest about the kind of debt that you incur. When you're actually in the day-to-day life of delivery, it's prioritizing your product work alongside your engineering work, and not putting yourself in a position where one or the other needs to take precedent. Both need to happen together.
Finally, it's about clearly communicating how the debt impacts. I want to leave you with this mad lib, if you will, for how to communicate the impact of debt. Our objective of a measurable goal can be improved by specific actionable task. If we don't address this, we will immediately feel the pain through some kind of quantifiable impact. In the future, we anticipate this long term implication. Measurable goal around a specific actionable task, a quantifiable impact of achieving or not achieving that goal, and the long term implications. Those are the four factors that you need to make a healthy decision around a product debt. If you do that, you're going to be able to actually build a product that is balanced and delivers value, that is well prioritized, and that is clearly communicated to the people that matter. Thank you. Thank you.
About the event:
Full Stack Friday is a monthly meet up hosted by Devbridge where we share insights on product development, design, and process. The talks focus on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.