We’re so used to innovating and building products and businesses for people, who have a need for what we are looking to go to market with that we completely forget about the other people.
While I totally understand why we never think about those, who don’t wish us well – it’s not the kind of thing you want to spend a lot of time thinking about – thinking about them may actually hold some merit.
Let’s think of it this way:
What are the scenarios where someone would aggressively try to detract other people from using your product?
And more importantly:
What can and should you do about it to try and counter it?
Maybe the answer to the last question turns out to be “Nothing. Haters are gonna hate.”
But just maybe it could spur a couple of twists to your products and services that not only deter the saboteurs from going crazy on your product but actually also ends up delighting your loyal customers even more than they already are.
If that is an option, wouldn’t it be worth spending just a little time reflecting on who your potential saboteurs are, and what you could/should do to counter them?
For quite a while I have been deeply fascinated with no-code platform Bubble. It’s immensely powerful in itself, and it allows no-coders like me the opportunity to dabble a bit into it and try to get an understanding for how code structure actually works.
But it also presents another huge advantage: An improved ability to understand and communicate with coders.
Here’s how I am trying to do it:
The Bubble editor contains a number of separate workstreams. Two of these are Data and Workflow.
Start with Data. Here you can define the properties that should go into your database, ie the different datapoints you would like to capture, store and manipulate as either part of a function of your service or the user itself.
You can essentially map out your business model here. Think about what you need to capture, and what you need to be able to do with it. And make sure that your database is structured based on it using telling labels etc.
When you have your database table in order, you move onto Workflow.
Here you can pick out individual labels from the database and basically do a IF THIS THEN THAT analysis on them and just map them out one by one. You can do this through fx a mindmap where you specify that when you’re looking at this function or feature, and a specific thing happens, the result should be something like this. And then repeat the process, until you have all aspects mapped out.
Using this approach you will end up with a serious of pretty well-structured maps that will illustrate your core functions and how they should operate and spelled out in a way that should make it easier for you to have the conversation with the coder(s) who are going to build something.
Because even if you can’t completely speak their language, you have at least made a real effort to try to bridge the gap – and all things considered you will be a lot closer to a fruitful dialogue.
It is not uncommon to see new products launch with a lot of features. Too many features, perhaps.
The rationale is fully understandable; there is an urge to get a ‘finished’ product out, and you quickly form your own opinions about what that means in terms of feature set.
The underlying rationale behind it is more important though:
When you launch with a lot of features, essentially what you’re hoping is that there will be something in there that will get customers to love and adapt your product and not just turn the other cheek – or not notice it at all.
I think it’s fair to say it’s ‘fear of failure’. Pure and simple.
And I also think it is fair to recognize it as such. Because when you’re developing new products and trying to do something that perhaps no-one else has done before you, your biggest fear is that nobody is going to like it.
Or worse: Even care.
In fact I will argue that it’s the key reason why so many still fail to test their ideas and assumptions before they go and build their first product; the basic fear of getting the idea rejected by the market, before it all even begins.
But then again, I don’t think there is a way around it. I think the only way forward is to ‘bet on less’ – even if it’s super tough – and do whatever you can to nail the things you do rather than risk being ‘all over the place’.
Thankfully, we do have tools such as the ability to identify our assumptions, form our hypothesis and run smaller scale, appropriate experiments towards them to get more insight and data on whether we’re on track to something.