If you follow my writing, you know I have two strong beliefs:

• Time to market is the key to success
• Value iteration above all else

However, companies still get spun around the axle future-proofing their software before release. I don’t know about you, but to me, that sounds like waterfall development. I thought we were past that?

Have you ever been in a situation where your team committed to getting a project done in a certain amount of hours, but you went over because a piece of configuration was a bit more complicated than expected? And come to find out your clients don’t even use that configuration?

It’s frustrating to you because you spent all that time coming up with a robust set of configuration that nobody uses. It’s frustrating to your clients because you delayed getting their software because of configuration they don’t want.

So How Do We Change?

Hardcode it. Unless you specifically committed to building a piece of configuration, just hardcode it. Place value on iteration. Quickly get the product to your consumer. Let them see what they like and don’t like.

You’ll be amazed how many people are happy without configuration they think they need.

Let’s take a look at an example. Your team is responsible for building a sandwich ordering app. The app presents users with a list of ingredients they can select before they hit submit. After they submit their order, it goes to the cooks who then process the order and deliver it to you via bicycle. Very 2019.

Image by Kai Pilger from Pixabay

But someone on your team has the idea to introduce a “the usual” concept. The user logs in, sets their ingredients for the sandwich they order all the time, and hits save. Now they have a one-click order option.

Somebody else suggests adding configuration for the cooks to mark when an ingredient is out of stock. Seems necessary so you don’t have orders missing ingredients, so you add that into the mix.

Another person brings up that you need a priority membership. People can pay to become pro members so their sandwich orders bump up to the top of the queue automatically. Pay more, wait less.

Before long, you have a list of features and configurations that have easily doubled or tripled your time to market if you build them all. What do you do now? Delay the release?

No.

Hardcode what you can. Omit the unnecessary features. Get some user testing in before building out all your features.

Build, measure, learn

In the book Lean Startup, the author talks about the principle of build, measure, learn. In short, it is a feedback loop that helps you iterate and improve your product.

Diagram adapted from Ries, E. (2011) ‘The Lean Startup,’ New York: Crown Business.

Build something small. Measure feedback from customers. Learn from their needs. Then start the cycle over again. Build one of the needs you just learned about. Measure if you met the need. Learn how it can be improved.

In our sandwich app, all we need to do is display a list of ingredients and take payment. It displays the order on a screen to the cooks. The cooks mark the order complete. The bicyclist delivers the order. Iteration 1 complete.

Show it to your customers. Get their feedback. Turns out they really need the ability to mark ingredients out of stock. Learn where the priorities are. Go build it.

Maybe they never bring up the idea of “the usual.” You saved yourself time that you could have been innovating. By omitting or hardcoding features that could have been configurable, we allow ourselves to spend our time building what the customer truly wants.

Do People Really Do This?

Yes! Many companies are out there right now changing the world by building products and services that we actually need. In fact, if you take a look at the GitHub flow, you can see this is the model they follow.

GitHub Flow from GitHub

The GitHub flow proposes that you deploy a new feature to production before merging it to master. So getting the feature out in front of your customer base before considering it gold or even feature complete is the main idea. Doing so enables you to verify the feature is something your customers will use.

What do you call software your customers are happy to use? A market success.

This is a strategy that many startups follow. You won’t be alone or trodding new ground if you go down this route. You will be joining the thousands of other companies in the happy customer club because you will be getting software they want to them quickly.

Call to Action

Don’t overthink it. Software doesn’t have to be hard. The best architects make simple solutions of complex problems. How do they do that? Hardcoding it. They don’t dirty up the water with unnecessary configuration.

They get the problem solved the fastest they can to get exposure. They measure their success from the feedback of their customers. They learn about the needs and new features that are necessary.

I’m not saying you need to throw everything away you’re currently doing, but consider being more agile and getting your customers exposed to ideas earlier in the process. Don’t let you hold you back. Value iteration. Value simplicity. Value a market success.