The Toon Smart Thermostat is one of Europe’s leading Smart Thermostats. With a growing user base, customer support was facing a growing range of diverse questions on whether Toon, being a connected product, could not be connected to other products like smoke detectors or social networks. It proved to be a challenge to our roadmap.
I was part of the team that built Toon, so may I share a hypothetical situation with you?
Let’s say, we have a question like: “I would like to connect my thermostat to Twitter. So that when I post a tweet with #almosthome, the thermostat would make my home comfy”.
Originating at the support desk, this question would eventually end up at some product manager’s desk. Now what? Should a smart thermostat connect to Twitter?
Say “No”
The obvious answer is to say “NO” to this question. Or to these types of questions. Because there are more items in the backlog. More important items. More “big ticket” items. Because you won’t sell more thermostats with this feature (the customer requesting it has already got one). There is limited business value. And it is just “n=1”. And starting with Twitter, very soon we would need to start building links with Facebook, Instagram, Whatsapp. Doing so would result in a bloated product that eventually, no one will understand. And then we need to maintain the connections with Twitter and the likes. Therefore, we say “No”.
Or should you say“Yes”?
I thought about it some more. Because what if this customer is one of the firsts to have bought your smart product? And what if he has proven himself as an enthusiastic ambassador of your product? And he is one of the most active forum members.? A forum that – by the way – was built to solicit feedback from the user community, so we could further build out our MVP responding to what users have want.
Isn’t this exactly what we wanted to happen? And with building a connected or smart product (even as an industry), did we maybe give rise to the expectations that connected products would connect to all other connected products and services? And didn’t we suggest we would have frequent software updates with new possibilities?
This is thé opportunity to show our users that we listen and we take their ideas into serious consideration. And we have to, because we have already said “No” fifty times in the past month.
So what happens to your roadmap?
We can’t possibly argue about this n=1 case for too long, so we compromise. It is neither No, nor a straight Yes. We tell the user that the product team is considering it, and we put it on the backlog for some point in the future. And we label it as nice-to-have. After all, it is only a small development that could be done in 1 or 2 sprints. We might get to it at some point. And maybe n=1 will become n=100, maybe we run out of ideas at some point, maybe we have some time left some day.
Sounds familiar?
The reality of course is that nothing happens. The label “nice-to-have” is a euphemism for “we are not going to do this”, or, “there are more important things”. We fool the customer with politically correct answers about how great it is that he thinks along with us and we consider his suggestion. Until he stops thinking along, and stops being an ambassador for our product. And nice-to-have things actually don’t happen, because we have too few resources to implement them anyway.
This is a lose-lose situation.
The customer thought he had a valid question and gets disappointed. Forum moderators and customer support staff have to provide bogus answers. Product managers have to say “No” all the time. Developers may – deep in their hearts – want to make this happen, but they can’t. Backlogs and roadmaps are a graveyard for more than half of listed features and ideas that will never succeed.
Multiply this by 100, just for your organization alone.
A radically different approach to your roadmap
Now consider the following: what if the forum moderator could say: “Sure, this is possible. Why don’t you connect your thermostat to Twitter yourself? Here’s how …”. Or even better: “Yes, I can help you. Let me share this with you. If you follow the link and type your password, it’s done …”
The customer is happy, the support engineer does what makes him happy (and was hired for). The product manager is happy because this keeps his backlog clean and he can keep an eye on the roadmap.
On top of that, he’ll be able to get data on what users actually do want the product to do. He no longer has to prioritize small ticket backlog items with unknown business value, the end-users decide what is valuable to them. And this feedback is quite helpful to get better insights and to prioritise the backlog further. If customers start adding functions to products themselves, what better proof is there?
Olisto is here to address this issue.
To have connected products easily work together with other products and services without the technical hassle. Because, in many cases, the missing function of the one connected product, is perfectly available in the form of some other connected service. Connecting your product or service to Internet opens great opportunities and we help you take those opportunities.
If you recognize the above situation and want to do something about it, drop us a line and let’s talk. If you connect your product to Internet, let us help you to have it work together with other products and services. So you deliver what matters versus build what matters.
I look forward to talking to you. Leave your e-mail address or hook up in our chat-screen below this post and let’s keep in touch.
Do you want to know more?
Leave your email address and we’ll be in touch soon!
