UX and Technical Debt

Marketo Retrospective Part 6
As part of a series, I am doing retrospective lessons from my 9 years at Marketo. Today, I focus on product development. Specifically about a philosophy I have around maintaining products after initial innovation.

When you have a startup, the first innovation is complete free from existing customer complaints. It is pure in that sense. It is only after you deliver that first product and customers are using it that you start to accumulate UX and technical debt.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

From my 2011 blog post on technical debt.

Notice how the quality goes down exponentially with technical debt.
Notice how date driven releases contribute to technical debt.
Notice how new features are delayed because of tech debt

At Marketo, the technical debt load was very high. Part of this was cultural. We were strongly dissuaded from refactoring and improving code. For every one engineer like Crash who optimized code as he went, there were dozens who cut corners to make deadlines.

The real culprit here is date-driven development. This is when you focus on the deadline instead of the quality of the release. Usually, it is executives who pressure the team, not the team itself.

UX Lesson #9: People don’t remember the date you released your product. They remember the way it makes them feel. Focus on that.

Because refactoring was verboten, the focus became solely about new features. This created a very large codebase, but because of the debt, slowed overall development to a crawl. Ultimately, this became crippling. As a designer and product leader, I couldn’t stop the degradation of the experience without a massive payback of the debt. (In other words, rebuilding the application from the ground up)

No one likes paying technical debt, but it is crucial to the longevity of a product. Marketo made the mistake of driving development to a date, thereby causing cut-corners (technical debt) thereby slowing development down. It’s a vicious cycle and it sucks to be inside of it.

A series of acquisitions (social, mobile, RTP, SEO) made matters worse by introducing new codebases, new people and taking oxygen away from much needed existing products. There is this great post in the Marketo community from Gregoire Michel that basically lists a ton of UX/Technical debt. I wish that stuff could get the attention it deserves.

I take plenty of blame for the situation. Although I could say that it was other people who made the decisions, I was there and it happened on my watch. I did not persuade the powers that be to focus on usability, refactors, upgrades and feature completion. I rolled over and accepted that we were moving on. I tried to maintain balance, but in the process gave up my values about how products are built.

In the end, my lesson was mostly about what happens when you ignore technical debt and how lack of persuasion on my part led to this outcome. It is a poor leader who blames others for problems. Maybe with the new ownership Marketo will change their formula on paying debt. Time will tell.


One response to “UX and Technical Debt”

Whatya think?