What It Takes to Actually Ship a Piece of Commercial Software
Last week our startup, MarkedUp, hit the first important milestone for an early stage technology: we shipped the first version of our analytics product and put it into the hands of actual end-users.
For those of you who don’t read my blog regularly (pretty much everybody, I suspect,) MarkedUp provides in-app analytics for desktop application developers. We’re focusing our company’s initial efforts on supporting Windows 8 and WinRT developers specifically.
Now, we still haven’t completely opened the doors to everybody – we’re capping registration for MarkedUp through the use of invite codes while we gather important UX feedback and reports on bugs we may have missed.
Nonetheless, we hit that important milestone and have live users! Yay!
However, here are some interesting facts about the timeline leading up to our ship date:
- We were feature complete, with high test coverage and few known issues, a full two weeks before we were able to ship;
- We didn’t have a design for the marketing parts of our site, like the homepage, until 48 hours before our launch;
- We actually cut features from the product the night before our launch;
- We started the process of gathering user feedback when we were about 50% finished with the first version of the product – by then we had demoable charts and tables (features of our analytics product) we could show to target users.
We weren’t able to ship for two weeks, two weeks (!) after we were feature complete – and we cut features the night before we shipped? Are we a bunch of crazy incompetent bastards? No!
Shipping Software: More Than Just Code
This wasn’t my first time participating in the ship process for a piece of software, but this was my first time running it.
I suspect my opinion on this will change the more often I do it. In my estimation, the time it takes to design, plan, and code the core product and its features constitutes only 40% of the actual work required to deliver a software product to market.
So, what were the things we spent our time doing leading up to launch?
Great question, I’ll break it down by category:
- Feature development and functional testing – 40% of time;
- Pre-launch UX testing and refinement – 20% of time;
- Creating a demo application – 5% of time;
- “Marketing engineering” – time spent coding features responsible for driving users towards conversion goals – 10% of time;
- Graphical design / branding (largely outsourced) – 5% of time;
- Writing documentation, tutorials, and setting up support infrastructure – 10% of time;
- Writing and proof-reading marketing copy – 5% of time;
- Planning and executing roll-out marketing – 2.5% of time;
- Planning and executing roll-out software release – 2.5% of time.
One thing to bear in mind about these numbers – this was for a soft beta launch, not a top-down, TechCrunch-style launch. The amount of time spent on things like roll-out marketing is astronomically higher for a massive top-down launch.
What’s the trend here? Most of the the time we spent working on the product was spent on usability issues.
Like Jeff Atwood says, your app is merely a collection of details. There’s really two classes of details that matter:
- Details that affect how the user engages with your product and
- Details that affect how the user understands your product.
Marketing engineering, demo apps, copy writing, and graphical design are all investments we made into helping make our product easier to understand.
Documentation, support, and UX are all investments we made into helping make our product easier to use.
The bottom line here is that the auxiliary stuff needed to support your product, like documentation and support infrastructure, take a lot of time to do well. They’re as much a part of your user’s experience as the software is itself.
Shipping the Right Features at the Right Time
So we cut features right before we shipped, literally 24 hours before I pushed to production – why?
The answer is simple: we have specific goals for what we want to learn about our users with this version of our product. Any feature that we considered to be too unpolished, too complex, or too distracting was cut – even if we had a reasonably good implementation of it ready to deploy.
Every software release should be purposeful and careful – if you overwhelm your users with too many features and options during the first release, your user feedback gets diluted across that feature set and you never get a chance to learn what you are fundamentally doing right or wrong!
If you ship a bunch of poorly implemented features, you might churn through all of your early users way faster than expected and have to subsequently work harder to acquire enough users for the next iteration. If you ship a bunch of “distracting” features, you detract from the feedback that really matters to your business.
Ship software with the intent to learn and test very specific things in that release. Don’t ship for shipping’s sake.
Discussion, links, and tweets
I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..
Tweet Follow @Aaronontheweb