Technical Debt & the Race to MVP

Not being able to validate an engineer's estimate or decision on technology is a huge obstacle to success for the less experienced, and sometimes even the veteran, product manager.  But intimately working with technical leaders is essential to getting an effective product to market quickly.  Finding the fastest path to MVP could be the most important goal a startup can achieve in the first few weeks, but before we talk about product, let’s unpack the world of engineering and technical debt.

Most engineers that have inherited someone’s ‘project’ know how painful bad technical design choices and historical short cuts are.  A recent technology that I worked on had been built with all the date/time stamps recorded in a particular time zone.  When we did the analysis on how many places in the code “needed” to maintain this standard because of workarounds that other developers had designed on top of this flaw, the number was in the thousands requiring a permanent acceptance of this massive hurdle.  It’s painful to accept when you consider that a choice of using UTC would add a few hours at most to the initial effort.

'New' and 'scalable' both have steep initial costs

We can agree that we should never make a poor choice when a good choice is easily available, but it’s not so obvious when we battle with the choice between ‘speed’ and ‘scalable’.  In a recent project we have had several discussions on security and the use of sophisticated authentication services vs. simply building a basic username/password system.  No one would argue that the sophisticated security is far more safe, far more future proof and far safer for users.  But 'new' and 'scalable' both have steep initial costs, as the implementation of a new and complex system requires learning, testing, trial and error and far more implementation demands.

A decade ago I met an entrepreneur who invested several hundreds of thousands of dollars of development into a scheduling software product built on top of WordPress.  An amazing blog platform, for sure, but making it do what it wasn’t designed for led to the unfortunate realization that they were still a year from an MVP - an eternity for a startup.  They were evaluating whether or not starting over would be faster.

But then there is Groupon, the fastest startup to achieve a billion-dollar valuation. I have read that they launched using WordPress.  So why did it fail for my entrepreneur friend, and succeed for Groupon?  It turns out the answer is painfully difficult to conclude, but at the heart of building an MVP.

Let’s take the business founder’s perspective.  They’d say, ‘I don’t care if it is made of cardboard, if it proves that we have a market we can raise funding and build our company.’  They are unarguably correct.  After all, what good is a scalable database, an iron tight security system and well documented and testable code when there is no business to fund future development?  *But* this means that one must accept that the cardboard must be replaced with a scalable product at some point in time and investors will most likely assume that the foundation for that already exists.  So that’s not an option unless you want to be apologizing to investors for the first six months as your team rebuilds your footing.

So then let’s examine the engineer’s perspective.  They may say, ‘The new version of this framework just came out, it comes with very advanced new tools and sets us up for scale.’  But then if you ask, ‘How long will that take you to learn and build vs. using the usual stuff?’  And they will likely give you an estimate that is many multiples longer to get to your ‘first time to customer’ moment.  Even if you are some strange creature that doesn’t care about time and money, you can still miss the market rendering the really scalable thing you built almost useless.

Beauty is in the eye of the... customer

I started my career as an engineer so I know how tempting it is to over-engineer a feature or a part of the infrastructure for several reasons including, 1) we’re here…  let’s maximize our mental scope, or 2) just a few hours more work will yield meaningful future benefits, or simply 3) this is crazy cool stuff and I can’t help myself.  I know each of these feelings so it is important to remind ourselves of two very important concepts.

The most value comes from the first 20% of the project and the most time is spent in the last 80%

First, time is money.  Every day spent working on something means one less day of runway for funding or to get to revenue goals.  In the beginning, if 80% of your work isn’t getting you to your goal, you should not be doing it.

Second, in my experience, the most value comes from the first 20% of the project and the most time is spent in the last 80%.  So move on when you are done with most of the value, not when it’s perfect.

For example: after permitting is done, most people that have a new home built get excited when they see how quickly you can get a foundation, frame and roof on a home just to find out that as related to the schedule, they are nowhere near halfway.  This is because it’s the last finishes that cost the most time and money.  So am I saying that you shouldn’t put in the windows and fixtures?  And I’d answer, “It depends”.  If the homes are to be built quickly for 100,000 refugees that have no roofs over their heads, then yeah, skip the fixtures and move on to the next home.

Waiting for perfection means waiting for market feedback and you need that far greater than a few minor issues here and there.

So you may ask, ‘Are you saying that we should launch unfinished or worse, with bugs?’  And I would say, ‘Sometimes, yes.’  Waiting for perfection means waiting for market feedback and you need that far greater than a few minor issues here and there.  Even if you are working on a medical device that must go to market flawlessly, in the phase of funding, research or innovation, perfection can still be a distraction.

If you plan in epics (a group of features for a business objective), you are well aware of the pages and pages of epics you will probably never get to.  So when you think, ‘We’re not done yet and I don’t like leaving things unfinished.’ Remind yourself of those pages and pages of value that you’re customer may never experience if you wander into that last 20% and swallow your capacity for delivering maximum value.

Know your priorities

Ever wonder why medical devices or your car’s in dash UX is so crappy?  It’s because it isn’t the main purpose for those products.  A person working on a new medicine delivery system for a diabetic which frees people from needles shouldn’t be worrying about how sleek the UI is going to be.  It just needs to be “good enough”.  This may seem obvious at this level but it is not so obvious when you are in the nuts and bolts of planning or building.

If you’ve worked with as many engineers as I have, you know those engineers that write really confusing disorganized code that somehow works.  Let me be clear, code like that is technical debt that will come back to bite you some day and should be heavily considered for a rewrite project.  What I am referring to is the desire to polish everything we do.  

I recall a project that an engineer and I worked on where we were trying to automate a manual process that our customers went through every week.  The engineer was unsatisfied with their code saying, ‘It takes 5 seconds to run.  I know I can get it to under a second if we wait until the next sprint to release it.’  My response was, ‘It takes the customer 5 days to do this today.  Launch it.’  Going from 5 days to 5 seconds was our win here.  Should we work next week on making that feature run in 1 second or find another 5 days to save for our customer?

You don’t need to keep everything

Of course you must avoid painting yourself into a corner of technical debt if you believe that your code will be in use a decade from now, so be diligent about where to start and stop each project.  However, sometimes you can just build something quick, to validate a need, then decide later whether or not to invest further.

One objective I was given for a startup I was working for was to build a subscription model for our pay per use product.  We sized it out as several weeks of coding.  After collaborating with the founder and tech team we decided to put a button and a small ad in the current pay per use checkout that encouraged people to sign up for this new subscription instead.  If you clicked it you’d get a message saying that the service wasn’t available in their area with a link to continue checking out.  We put in some tracking and we launched it.  It cost us a few hours.  With the volume of customers we had, we found out in just 3 days that we should not waste our time building this option. The idea was a loser, no one wanted this option, but the experiment was a huge win as we could move on to a more promising project.

Ultimately it comes down to people

In the beginning, there is nothing more important than calculated simplicity.

Great technical leaders respect the business enough to trim the edges of their decisions when required.  Great product leaders can both articulate to engineering what areas are important and what are not, and can also assess and report these decisions to the business leadership when needed.  But most importantly, great business leaders find very resource sensitive product and technical co-founders to work with.  If time is money, then good people can save you a lot of it.

In the beginning, there is nothing more important than calculated simplicity. Don’t be afraid to throw small efforts away to experiment, never choose a grossly inferior path to save a few hours, avoid perfection unless the customer demands it day one (very rare), build trust between yourself and the business and technical leadership through small wins, and always be frugal.