Shipping

A series on the Faithlife core values: Honesty. Openness. Awesomeness. Growth. Initiative. Elegance. Shipping.

It doesn’t matter how great something is if no one is using it.

We get paid when we deliver value to our customers. At the start, our idea -> implementation -> delivery loop was very short. We had an idea, we implemented it, shipped it, and got paid. Then we took the next idea and implemented it and shipped it, too.

Not only did we turn ideas into cash quickly, we rarely shipped a feature that wasn’t useful, we rarely wrote code that didn’t get used, and we were rarely beat to a new opportunity by a competitor. We had a tight feedback loop and could hear our customers clearly.

As the company grew the loop got longer and longer. The product was more complicated. We had bigger ideas we wanted to implement. We tried to anticipate needs, not respond to them. We had enough cash to take the time to do things right the first time.

This is a natural consequence of growth. And there are good things about it, and bad.

The danger is when your idea -> implementation -> delivery loop grows so long that you never complete the loop. You can discuss and meet and think about an idea so long that it never moves to implementation. Ideas that do make it to implementation can die there as they are tweaked, refined, improved, and perfected.

Companies can, and do, invest a lot of time and energy in things which are never delivered to a single customer.

And along the way there’s a danger of trading your external focus (on customers) for internal focus (on process/politics/co-workers). A short loop lets your customers tell you how good your ideas and implementation are right-away. A long loop involves a lot of investment without feedback.

Is there a danger of shipping junk quickly and damaging your relationship with your customers? Yes. There should be a minimum standard of quality. We value Awesomeness and Elegance, too. But an organization with a short loop can fix problems quickly. An organization with a long loop will suffer even more from mistakes.

How do you know when to ship something?

It can be hard to know. It takes judgment and experience, and even then it’s still a guess. There are some questions you can use to help you decide, though.

Are we trying to make this perfect? Perfect is the enemy of good. We don’t need it perfect, we need it shipped. Then we can get feedback, improve it, and ship again.

Can we split this project into phases? Are there obvious levels or stages or break-points in this project that would let us ship it in useful, but smaller, pieces? We can start shipping a commentary series with just Philippians, instead of waiting until the whole Bible is complete. Are there even smaller units? Could we start with just the most commonly preached pericopes in Philippians?

Can we test it manually? Is there a way to test the assumptions of the project using a much smaller implementation before investing in a complete one? (The first Logos Pre-Pub was administered manually, with no special code. Community Pricing was introduced and tested using Survey Monkey instead of Logos.com. The first payment plans were managed in paper file-folders long before automation was introduced. We proved the concepts before investing in implementation.)

Can we change this easily if we need to? Some decisions will be costly to change later (choosing your accounting system, hiring the right person, picking the coding language) and are worth taking the time to get right. But many decisions in design and implementation can be changed easily; don’t let those get in the way of shipping.

Is this the Minimum Viable Product? “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The MVP is more important at start-up then during the incremental improvement phase, but it’s a useful concept to understand and keep in mind even as we incrementally improve our products.

When I first started playing with computers I experimented with software and hardware. I had a soldering iron, built circuits, and hoped to assemble my own computer. But I quickly learned that not only did I need parts to build things, but a mistake with a soldering iron could break a part in an expensive way. Software mistakes, on the other hand, were relatively painless — I just changed the code on the screen.

There’s a reason we are in the software business. It’s well-suited to short loops, quick tests, and shipping incrementally. Especially now, with automatically downloading updates and web-based products.

Let’s get stuff out the door, so we can live to ship again.

comments

Leave a Reply

Your email address will not be published.

You might also like...