Confession time! As an engineer and founder who is eager to ship and get a product out into the hands of customers, I’ll admit there have been not one but more than a handful of times when I’ve deprioritized usability and visual design in favor of shipping a product that “works.”
And there have been other times when I may have strongly suggested to a designer that their designs were “too complicated” and needed to be changed to ease my workload.
Instead of thinking through how a customer would interact with it and paying down tech debt to implement the design, I pushed them to “put it in a new tab.”
You can probably predict what happened next.
The product quickly became complicated to use, and customers slowly started to drop off.
While that was a wake-up call for me, I struggled to figure out how to balance the workload of paying down tech debt versus product debt.
It wasn’t until a wise designer took me aside to explain the importance of paying product debt, and that I shouldn’t think about it as being at odds with tech debt, that I started to think more holistically about the two.
If you’ve struggled to deal with paying down product debt on your product team, or want to educate new teammates on how to manage it, then this Build Tip is for you!
I’m joined by Leslie Yang, who is a Senior Product Designer at Pivotal Labs, and here’s what we’re going to share in this episode:
After you’ve watched today’s Build Tip, let Leslie and I know how you handle product debt at your company in the comments below!
Poornima Vijayashanker: Did you recently show your designs to an engineer and hear this?
Ronan Dunlop: It is going to be challenging to implement in time for the next release.
Poornima Vijayashanker: Why?
Ronan Dunlop: They’re pretty complex.
Poornima Vijayashanker: Why are they complex?
Ronan Dunlop: This slider alone is new functionality that is going to take at least two days’ worth of time to implement on the front end, maybe more.
Poornima Vijayashanker: OK, what else?
Ronan Dunlop: To do these visualizations we’re going to need to pull in a lot of data, and that’s going to slow down the performance of the app. Some of these new workflows require changes to our current APIs, which have already accrued a significant amount of tech debt.
Poornima Vijayashanker: OK.
Ronan Dunlop: It doesn’t seem doable for the upcoming release. I’d recommend changing the designs.
Poornima Vijayashanker: I think we should go talk to Leslie about the importance of paying down product debt in every release.
Welcome to Build, brought to you by Pivotal Tracker. I’m your host, Poornima Vijayashanker, and I’ve got a new Build tip for you. Remember we talked about tech debt with Jay Hum from Pivotal? If you missed that Build, tip I’ve included a link to it below this video. Today we’re going to explore product debt. To help us out, I’ve invited Leslie Yang, who’s a Senior Product Designer at Pivotal Labs. Thanks for joining us, Leslie.
Leslie Yang: Thanks for having me.
Poornima Vijayashanker: So Leslie, tell me what’s product debt?
Leslie Yang: Great question. Product debt is the debt that a product incurs when the UX is really starting to change and cease to be as successful and helpful as it used to be.
Poornima Vijayashanker: Can you give some examples?
Leslie Yang: For example, you’ll hear someone say, “Hey, I want to test this new feature. Where should I put it? Let’s put it in the tabs.” You’re like, “Should we put in the tabs? Let’s go figure this out.”
Poornima Vijayashanker: What else?
Leslie Yang: Let’s see, so you can say that our workflow is complicated because our users have gotten so used to it, so we just end up annoying them or losing them if we change anything.
Poornima Vijayashanker: Anything else?
Leslie Yang: Another one is we just added a new feature and we want to promote it, so can we just add a button next to everyone’s name and just highlight the hell out of it? No.
Poornima Vijayashanker: These are all great examples I think of product debt that we have experienced both as consumers of a product, but also folks who are designing products?
Leslie Yang: Absolutely.
Poornima Vijayashanker: I’ll have to admit, as an engineer I have been guilty of ganging up on those designers responsible for deprioritizing product debt, and no, it’s not a good practice. How can we help people in our audience who are designers avoid being ganged up on and making sure that product debt remains a priority?
Leslie Yang: Absolutely. As a designer it’s great to be able to focus on the research, to focus on the user experience, but you should also focus on being a really good facilitator. Control the dialogue around feedback. Focus on the product vision and the product strategy and the business strategy and then connect that design feedback to it.
Poornima Vijayashanker: What does that look like in practice, as an example?
Leslie Yang: Let’s say, for example, a business strategy is to improve the number of active daily users for monetization reasons. You want to make sure that the user experience is focused on building up to that and meeting that metric. One more thing. You can totally work with PMs on this as well.
Poornima Vijayashanker: OK, so as a designer approach a PM? How would that help?
Leslie Yang: You can work with product on this by pulling the data and looking at it together and then figuring out where the areas you want to improve on.
Poornima Vijayashanker: Great, so it actually provides some evidence for why you need to pay down that product debt?
Leslie Yang: Exactly.
Poornima Vijayashanker: What about engineers? I’m sure they want to contribute and make sure that the conversations are useful.
Leslie Yang: Absolutely and I love that when engineers are in those conversations on product with us. What someone like Ronan could do if he was concerned about data visualization, he could come up to one of us as designers and say, “Hey, how does this idea of introducing data vis tools really fit in with the product vision? What do you think?” Just coming from a place of curiosity is really helpful. That creates this really positive dialogue.
Poornima Vijayashanker: He’s probably going to learn more and not jump to, “Oh my gosh, this is going to cause a performance issue and a bottleneck” and all this stuff.
Leslie Yang: Exactly, and I think riffing with, I love the riffing that happens between designers and developers because you can come up with some really creative solutions you otherwise would not have come up with separately.
Poornima Vijayashanker: What can teams do to continue to prioritize and pay down product debt?
Leslie Yang: What my belief is is that developers should be brought into work early and often. They should be in the feature ideation process. I will have devs sketch with us on UIs.
Poornima Vijayashanker: Oh, great. How does that help?
Leslie Yang: It makes a huge difference because by being involved early and in frequent times they’re able to contribute ideas and also understand and have user empathy. The work that we create together is not going to be overly complex. It will be well thought out and by the time that the work comes to them it’s not a surprise. They know what to expect.
Poornima Vijayashanker: These are fantastic tips, Leslie. Thank you so much for sharing them with us today.
Leslie Yang: You’re so welcome.
Poornima Vijayashanker: Leslie and I want to know, how do you handle product debt at your company? Let us know in the comments below this video. That’s it for today’s Build tip. Be sure to subscribe to our YouTube channel to receive more episodes of Build and great Build tips like today’s. Special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.
This episode of Build is brought to you by our sponsor, Pivotal Tracker.