This is probably the most difficult part of my job
Deciding what to build next is tough — here’s a things I consider before making the decision
Coherent is a young company. It’s a small company. And we’re growing quickly. A big chunk of the work I do is around the product; design, development, management etc. The hardest part of all of these things is answering the question “what do we build next?”
We have one in-house, full-time developer on our team, in charge of building new (small) features and fixing bugs. We work with a development house to build big features every few months, but on a day-to-day basis we have just one developer, so we need to maximise the value created (in the form of features or fixes) with every hour of work he does.
We have customers and prospects that are all at different stages with the product — some have been using it for months, some for a few weeks. Some have expressed an interest in signing up but need a few more features before they commit, others inevitably need more/different functionality before they’ll even consider it. Long story short, they all have different answers to the question “what do you want us to build next?”
On top of this we have two very different types of user: coworking space owners, and coworking space members. Both need very different things from our platform, but we need to make sure that both are getting value out of the system.
There isn’t really a perfect strategy for deciding what to build next, but here’s a couple of things that I think about when I’m looking at our ever-growing wishlist of features
Has the feature been explicitly requested by a user?
Users know what they want from Coherent far better than we could guess. We want to build Coherent into a product full of features and functionality that users actually want, and not fill it with “stuff” that no-one actually wants.
It’s also important for us to make sure that we’re constantly developing and supporting the product. For interested prospects, the thought of going through an onboarding process, and then finding that there’s no ongoing support for the product, to the point that they have to switch services, is worrying. By regularly building features requested by users, we can instill trust in potential customers that just need a little nudge over the line to sign up.
What I’ve learnt however is that it’s important to look into how many users have requested this feature or reported a similar problem. It’s easy to listen to the ones that speak up, and build their requests feeling good that we’re answering our users. But in reality the majority of users won’t speak up about requests or problems, so it’s important to speak to the silent majority to make sure we’re building features for everyone.
If it’s a bug, how many people does it affect? How serious is the issue?
I make a 2x2 matrix in my head with how many it affects on the x-axis and the seriousness of the issue on the y-axis. If it’s in the bottom left quadrant, it’s not a high priority. If it’s in the top right, it needs looking at ASAP. If it’s in either of the other two quadrants, it shouldn’t jump straight to the top of the list but should probably be investigated after the current feature has been finished.
What are the marketing benefits we can get out of building this right now?
Every time we release an update, no matter what size, or what’s actually in it, I write a public blog post and feature it in our weekly newsletter. Obviously if it’s a release full of edge-case bug fixes, the value of that from a marketing perspective is relatively small. But if we’re releasing an update with tonnes of brand new features, there will inevitably be more to write about, and its appeal will be far greater.
Depending on the update, they often give me an excuse to go back to prospects who haven’t quite crossed the line and signed up to say “hey look we just added this thing”. Even if that’s not a thing that they’d been waiting for, if it allows me to start a conversation with them again, and it proves to them that we’re listening to our customers and continuously improving our product, then building that specific feature can be incredibly valuable
All-in-all there’s tonnes of questions to ask before deciding on which features to build next, and at the end of the day, most of those decisions are made on my gut feeling, that takes all of these things into consideration
If you’ve got any methods you use for deciding on what to build next, let me know, I’d love to hear them!