Simple strategies to never lose sight of the most important weapon in a startup — shipping.
Just over a year and a half ago, my Co-founder Kate asked me if I wanted to build products for the moving industry — an industry where a majority of businesses today run on pen and paper, or outdated software. A few months prior to that, she’d started Oncue as a booking service for local movers.
When I signed on, I knew nothing about the moving industry or its pain points. While I’d built many consumer apps and products previously, I couldn’t claim to be seasoned at building SaaS products for a vertical — one where more and more business owners understood the value of having software to track sales, streamline operations, and effectively run their business.
I had to learn how a new industry functions quickly and more importantly, build a product from scratch and develop a culture of continuous and rapid shipping.
A Delicate Dance
In startups, the speed at which you ship (and therefore evolve) your product or service can make the difference between survival and death.
Take too long, and you risk learning valuable lessons sooner. Be too fast and furious, and you end up shipping things plagued by lack of quality and finesse. It feels like trying to drive with one foot on the accelerator and another on the brake.
How do you achieve speed, maintain direction, and deliver the right thing?
While I don’t claim to have all the answers, one thing we’ve done well as a team is to continually evolve the product, iterate, and add value in a consistent manner.
The journey has been rewarding and educational, but by no means smooth.
We were failing badly in those moments of customers screaming for features and feeling frustrated with our product. Moments where they say your product is too simple (it’s still simple to use, just more advanced). Deals were lost because our product wasn’t up to the mark.
When I look back to the first versions of our product, I’m mildly embarrassed. When I see our product today, I feel proud to say that I see a gamut of possibilities. It feels like we’re just getting started!
Before I dive into my learnings, two things:
- These will resonate with you more if you’re building software products, where you have the luxury of iterating from one version to another in a matter of days. Hardware or manufacturing is outside the scope of these learnings.
- While shipping consistently to me is like breathing, it is not crutch to compromise on the quality of your product or making sure you’re build the right product for your customers or users.
Here’s what we did right.
Build and preserve momentum like your life depends on it.
In my experience, momentum determines everything. It is highly effective as a motivator and keeping morale high. I also think present momentum is a great predictor of future progress.
At Oncue, not a week has gone by when we haven’t pushed some incremental update to the product. In a year and half, we’ve racked up more than 475 releases.
But there have been some rough phases.
We’ve spent too long on some features — the worst being almost two and a half months. In those weeks and months, it felt like time had come to a standstill. Everyone started to feel a little less excited about the feature. The product started to feel stale. While I was dealing with trying to get the feature together and keeping customers excited and morale high, juggling new requests at the same time posed its own set of challenges.
These situations aren’t always preventable, but I now try to recover from them as quickly as possible, and catch them sooner the next time around.
Whenever possible, I break up big features into atomic updates that can function on their own.
Want to track and report on open and click rates on your transactional emails?We’ll ship the tracking piece in one sprint, and reporting in the next.
Want to make file uploads and attachments available? Basic uploads and viewing attachments goes in one sprint, editing existing attachments in the next, and fancy browser for the attachments in another.
Push the product further one bit at a time, no matter how minor the change may be.
Find the right balance between polish and progress.
On a daily basis, I find myself grappling with decisions on whether to ship a feature, or continue to make it better and polish it. Launch it in its present, ready-to-use state or work at it another three weeks and make it do more? These are tough decisions, and I’d by lying if I said, I’m comfortable with all the choices I’ve made. I’ve lost count of the number of times I had to ship something knowing fully well that we could make it better.
For instance, there are more than a few screens in our product that could use some UX and UI love. Some workflows that can be twice as good. I see them in my dreams. I know it’s dirty. But they work. And customers continue to use them, and derive value from them.
The real world is unsurprisingly, messy. Engineering is hard. Things take time. You run into blind corners. There are edge cases.
The backlog of product capabilities that customers have asked for yesterday doesn’t take a break though.
I still see the warts, but I don’t lose sleep over them.
It is a vastly better approach to circle back to make something better, but after having gone to battle with it.
Dog-food your product at every step.
At Oncue, our sales reps use our product day in, day out. This creates a feedback loop that has been incredibly valuable. The feedback-fix-improvement cycle on many product capabilities is therefore much quicker.
This may not always be possible. If you’re solving problems for a vertical, ideally you have strong domain expertise. If you don’t, you’re going to have to construct channels that provide you with early and rapid feedback.
Perhaps cultivate a group of alpha testers amongst your customers?
Create a fictitious company and ask employees to use your SaaS app?
Building in the dark or based on gut/assumptions is an invitation for nasty surprises, often much too late.
Whatever it takes, find ways to create extremely quick customer interview/iterate/feedback cycles.
When possible, being your own customer is invaluable.
Avoid rabbit-holes like the plague.
This one is my favorite. Mostly because it might be the most common sin.
It’s tempting to design features that look incredible in Sketch, but will take your engineering team twice as long to build (and are most likely not optimized for user experience anyway).
It’s tempting to prematurely over-engineer your technical infrastructure.
It’s tempting to spend days automating something when a manual solution will do just fine for some more time.
It’s tempting to spend too long debating tools and processes and code and design patterns but not pick something that works well and move on.
I’ve committed each of these errors at one point or another.
But they are all rabbit holes. They slow the march. They suck more time than is necessary, and distract from what is truly important.
As product owners who care about every last detail, it’s tempting to want to fix a nagging issue or clean up that Settings interface that looks ugly. Who doesn’t want to clean house? Stop. Question if it will have a material impact on the customer’s decision to buy the product, or continue to engage with it. The answer may likely be no.
Be ruthless in doing things that need to be done, not the things you want to do.
Conclusion
As an early stage company, we don’t have the luxury of spending long cycles on things that will not lead to answers quickly, or make our customers more successful.
I’m in no way advocating for shortcuts, cutting corners, or building a poor product. But I believe it is critical to foster a team ethos that understands the right trade-offs and is comfortable with making those choices.
There’s only one priority — solve the right problem for your customer, and do it better and faster than others.
Focus on it.
Customers have too many choices. Let’s make them fall in love with our work by continually delighting them.
doublingdown.wordpress.com 