If you’ve been involved with any software-based business then you are familiar with the impossible challenge of achieving perfection. You have either been the victim or the perpetrator of crimes against your product team’s efficiency. This article will give you some ideas for how to find your efficiency sweet spot for whatever feature or launch you’re working on right now.
Have you ever…
…gone way over budget building a perfect feature with every use case and edge case covered?
…struggled to choose the perfect domain name, design the perfect logo or find the perfect colors and fonts that your whole team agrees on?
…waited too long to launch your site because your messaging wasn’t perfect yet?
Being ugly is not your biggest problem.
Don’t strive for perfection, there’s a law of diminishing returns that’s working against you.
The last 20% of your journey to perfection will probably take 80% of your team’s effort.
An Example From 2009
We’ve been careful not to waste any time since the day of our major pivot. Just take a look at our very first homepage from 2009 if you don’t believe me:
You think we spent more than an hour making that bad boy? No way. At that stage it didn’t matter what our website looked like, being ugly wasn’t our biggest problem.
Our bigger problems were probably similar to some of yours:
- Addressing customer feedback quickly
- Raising awareness of our product
- Experimenting with new distribution channels
- Figuring out what messaging resonated with our ideal customers
- Testing pricing hypotheses
Do you think having an ugly website got in the way of any of those things? Nope.
As the guy in charge of a tiny team, I was happy to be able to focus on our bigger problems and not get stuck on making a perfect website. In fact, not spending money on a designer and not spending time worrying about every pixel is a big reason why our business got off the ground in the first place.
If we had spent more cycles worrying about design, we would have wasted precious resources.
Our M.O. In 2014
In order to write this article for you, we got together and deconstructed the things we do on a day-to-day basis to minify every project. We’re not perfect, but we certainly get a lot done with a tiny team, and these are the things we do to make it possible.
When you find yourself predicting what your customers will want, stop. You’re probably wrong.
We all have a tendency to think we can predict the future. It’s natural. It’s also dangerous and expensive.At the very least make sure you’re talking to actual customers (or ideal customers if you don’t have anyone paying you yet) about your predictions before you turn them into projects.Most of the “scope creep” I’ve seen throughout my career has been due to this personality flaw, that’s why it’s #1 on my list.
Don’t build it unless several people are asking for it.
So someone asked for a feature? Awesome! At least you’re not spending time on a prediction that’s probably wrong.But do you have enough data to know that this person represents a bigger cohort? Why not ask a bunch of people first, or just put her on a list and wait to see if more people ask for the same thing?Lots of CloudSponge customers will tell you that I’ve said “No” to their feature requests, the conversation in Intercom usually goes something like this:
People respect this answer, trust me. Try it sometime.
Do it manually for as long as you can before you build anything.
Ok, so you’ve got a bunch of people asking for something and you are certain that it’s a feature that you need. Now is NOT the time to start slinging code.Making your administrators do it manually probably sounds crazy or impossible. In our case, this is usually me (the founder.) Trust me, the investment will pay huge dividends. You’ll gather perfect requirements. ‘Nuff said.Plus, in most cases it’s a really (REALLY) great opportunity to engage with your customers. (You do that, right?)If you can manage to do everything manually at first, then you’ll know with 100% certainty that your development bandwidth is NEVER wasted. The velocity that you’ll get from your developers will surprise you.
Share your pain with everyone on the team before pulling the trigger.
Eventually, somebody who’s doing a manual task will cry uncle. When a manual task starts taking too much of somebody’s time, it’s time to start automating it with software. Almost.You’re surrounded by smart people who care about the success of your company, right? Before you start speccing a new feature or redesigning something, talk to them about the manual process you’ve been going through and the reason why you’re crying uncle now.First of all, you’ll get a morale win. Your team will appreciate all the work you’ve done to deflect this from hitting their development queue and they’ll love the precise requirements you’re able to share because of your manual solutions.More importantly, your product team will be able to take the data you’ve collected and turn it into a super-efficient cure for the pain you’ve been addressing manually.
Build the Minimum Viable Feature first to verify that customers actually want what they think they want.
Most of the time your developers will find a simple way to automate the part that has gotten painful to do manually. If you can slice it up and still do some of it manually, then do it.Otherwise, go ahead and build it with full confidence that your product team is working on requirements that are based in reality and they’re building something that will definitely provide meaningful value to your customers and your company.
Lots of buzzwords apply here. Iterative, Agile Development of Minimum Viable Product based on Customer Development to stay Lean and achieve Product-Market Fit before Scaling to avoid Optimizing Too Early.
To The Naysayers
Some people will say everything they can think of to get you to endorse a huge complicated project. By the way, sometimes it’s you saying these things to yourself.
Nobody wants to tell their friends about an ugly product
BS. If telling their friends about your product will make them look smart, they’ll do it. Period.
A perfect product will sell better
Maybe. But only if you’re trying to improve metrics that are already very good.
Driving traffic to an incomplete product is a waste of resources
No way. You need to be having lots of conversations with real people as soon as you possibly can. Start driving traffic on day 0. Watch their behavior and engage with them enthusiastically.
Doing it manually is a huge waste of time
Your development team’s time is your most precious resource. Every non-technical person at your company needs to do everything they can to make sure those resources are used efficiently. Even if it means signing up users by hand or processing transactions one at a time.
Automating it should be easy (my favorite)
Engineers love to say this and they’re always wrong. Save yourself a lot of trouble and don’t let them automate anything that you haven’t handled manually first.
How Do You Hit Your 80/20 Sweet Spot?
Obviously I love this topic. If you’ve been nodding and smiling as you’ve read this, then I desperately want to hear about what you would add.
What techniques are you using to make sure you’re always working on your biggest problem?