no

When I heard the amazing news – not one, but two of our early investments have been nominated for awards at the SPARKies, I felt a glowing sense of pride. Their products fit the popular definition of lean startups and Simpleweb was a key partner in guiding them into the marketplace.

Both OLIO and Ordable have super focused CEOs at their helm, but for many founders, it’s easy to lose direction on the mission critical requirements when you’re stuck deep into a development lunar cycle.

The natural survival instinct for many brazen product explorers is to slip a few more feature lifelines in to make sure you have a safety net when you land in the marketplace… “I’m sure if they don’t like that feature, then this one will grab them”…

Des Traynor, Co-Founder of Intercom warns against the dangers of saying yes in his blog post Product Strategy is About Saying No

“When your product gets traction, you’ll find yourself inundated with good ideas for features. These will come from your customers, your colleagues, and yourself. Because they’re good ideas, there’ll always be lots of reasons to say yes to them.”

Do check out the 12 reasons Des shares why startup teams usually end up saying yes. They probably sound awfully familiar…

5, 4, 3, 2, 1… Launch delayed due to indecision

In the early days of product discovery there are some tough decisions to make which could affect the overall success of the product. At this point, it’s vital not to get get caught up in a feature quagmire which starts pulling your mission down with every new step.

To help keep eyes on the prize, mapping out your product’s big picture using the user story mapping framework is a great exercise.

The user story mapping framework, as proposed by Jeff Patton, aims to visualise the whole story for your product. It’s a real world collaborative process for key stakeholders to get involved in – from the product owner to the development team and even salespeople. The framework encourages discussion around priorities and feature details before they hits the development backlog. The outcome is to remove unfocused, dry, static functional specs that get lost, or worse, misunderstood later on in the project. This means you can build a better backlog that will help you more effectively explain your system, prioritise, and plan your releases.

Once you’ve identified the early assumptions you make about your users, sketched out your big ideas and filled in the details, you should have a pretty good understanding of the task ahead of you. If you can make some tough decisions to take a slice of the potential and deliver that, then you could be onto a good thing.

The quicker the product owner can say no to 80% of the potential ‘could have’ features, the quicker they can focus on the toughest part – the ‘must haves’. This gets you ready to launch quicker, means you can validate your ideas quicker, gather real customer feedback quicker and get to world domination quicker…

If in doubt…

When it comes to mapping out product features I stick to my mantra of “if in doubt keep it out”. If you’re unable to justify why you absolutely need a feature for launch, you probably don’t. If you have any doubt, just drop it.

At Simpleweb we subscribe to the MoSCoW framework as a super useful way to keep the product owner focused throughout the build-test lifecycle. It helps to highlight and prioritise the business critical requirements way before you have any quantitative market research to hand.

An early MoSCoW table for one of Simpleweb's products
An early MoSCoW table for one of Simpleweb’s products

Backed with a Product Requirements Document (as explained in this awesome blog post from Jerry Cao), you’ll have enough business thinking to lead your team through some of the tougher days in the build cycle.

Waste not, want not

Of course you don’t have to just throw away the thinking around a new feature requirement that falls outside of the must haves. Push it to the bottom of the backlog and let it survive with rest of it’s super important mates. It will naturally bubble back up for air if it’s a survivor.

We keep a list of all the ideas that pop up during a development cycle that we call the ‘bucket of love’. Once we’ve finished the requirements of that particular cycle, we revisit the bucket of love, and get to work on the ideas we still like.

Life on mars

So this covers a startup bootstrapping and chewing the lean bone. But what about after those heady launch days, when you have market traction with lots of real users? Some may call it a successful product!

I was ready to write some more philosophical chuff when I stumbled on this yCombinator thread from one of the founders of our industry’s most successful lean startups – Basecamp. The sentiment from Jason Fried captures the philosophy you need to approach making decisions better than I could…

“It is our job to be editors and museum curators. We have to decide what makes it and what doesn’t for the benefit of the overall product and the overall customer base. No combination of yes or no is going to satisfy everyone, so we have to work on behalf of the majority.

Every company with millions of users has to say no more than they say yes, we’re just honest and up front about it about it. We don’t want to set false expectations or promise things we won’t be able to deliver.”

So No!

Let’s just end by removing the negative connotations around using the word ‘no’. Especially when used as a noun, it is the definition of a negative connotation. But I think ‘no’ is the new yes!

Become a no sayer and ship that product.

Related Stories