After reading last week’s Tech Hug, you’ll be great at identifying the 20% of features that will make your product a success. Let’s look at where to go from here.
When you specify a new product feature, the instinctive behaviour is to delve into a brainstorming session and write long, detailed product specifications. If that’s your path from feature conception through to delivery, then please pause for a moment and read what’s to follow. While the feature might have merit, how you specify and develop it will ultimately determine whether it will add value to your product or not.
Programming is easy, deciding what should be programmed is the hard part!”
Writing product specifications should be easy
Let’s get the word out there:
Writing product specifications should be easy
And they should be easy not because you are a technical wizard or have developed lots of products before. No! Those can help but they are not what really counts.
Writing product specifications should be easy because you have an in-depth understanding of how best to solve a problem for your customers.
The flip side: When you’re having trouble writing down what needs to be coded, please see this as the universe sending you a warning. You’re not ready for this step and need to go back to the drawing board.
Why not just iterate your product?
It might be tempting just to ‘get something out there’ and see how it goes. You can always iterate towards success, right? You can try, of course, but this is a wasteful process and will cost you valuable time and money.
What’s more, the lean mantra of ‘ship fast and iterate’ does not mean you should start with a poor product. The route to success is to build the smallest possible product that efficiently solves a customer’s pain point. If you haven’t yet worked out how to do that, there is no point starting to code. Don’t build a product before you understand what you need to achieve!
It’s very easy and tempting to come up with a feature workflow that makes sense to you in your meeting room but is completely unworkable for your customers – essentially sending you back to 80% waste!
Take action: Solve the problem before you start coding
Enough of this negative talk – it’s time for your hug. Here are simple steps you can take to make writing product specifications easy. Follow these to end up with a product that actually gives you business value.
1. Solve the problem manually first
Grab a pen and paper, perhaps a spreadsheet, a phone book, whatever it takes. The simpler the better. Start solving your customer’s problems manually at first. This is easy in the early stages as you won’t have many customers. Once you have more customers, choose a subset of early adopters and apply the same principle.
Continue improving your process until you feel you’ve worked out all the kinks. Once you get to this stage, you’re ready to automate and scale. Simply write down your manual process in detail and send it off to the programming team. Yes, writing product specifications just got easy!
James Caan started a £100m recruitment company with a tiny office, a phonebook and a telephone.
The Ultimate Guide to Minimum Viable Products
Concierge MVP vs Wizard of Oz Test
2. Fake it until you make it
Let go of preconcieved ideas of how best to achieve the end result. Even when you know what tasks you want to automate using code, programming is not always the answer.
Can you build the same solution without code, using existing software? Will throwing lots of people at the problem get you there faster? Could you hire a virtual assistant to ‘automate’ this task while you focus on other areas of your business?
As Dory would say: “When something is too hard…there is always another way.”
3. Write user stories, not programming instructions
Once you decide to start programming, describe the feature from a user’s perspective. Don’t worry about how the programmer’s will make this work – focus on the desired outcome instead. You’re paying good money for experts, empower them to solve the technical problems for you.
Here’s a tiny example to see you on your way, taken from the specs of a travel startup:
#1 Telling programmers how to do their job: “Add a dropdown to the signup box with a choice of travel locations.”
#2 Empowering them via a user story: “As a user, I can choose a location when I first sign up.”
It’s a subtle difference that will greatly change the way your team operates.
The topic of user stories deserves an entire blog series but I wanted to include it here to send you on the right track. Let me know in the comments if you like this sort of thing and I’ll happily expand on it in the future!
A note about money
I often use terms such as ‘expensive’ and ‘save money’ and ‘costs’. Perhaps you’ve just completed a large funding round and scoff at this poverty mindset. If you feel this way, then you’re missing my point. Even if you have a lot of money to spend on software development, it’s crucial that you ensure your efforts aren’t wasted.
Being clever about solving customer problems and identifying what works before you start coding is what will give you traction. I’ve seen startups with millions in funding still struggle to develop meaningful functionality. Their output might be high but it’s a question of quality over quantity. So, even if you have a lot of money, cut out waste at every level to create a lean, successful business.