This is the 2nd post in a series about mistakes I made as first year entrepreneur. This time it’s about how to determine what product you should build for your clients, because I learned a lot in this area.
Other posts in this series:
- First Year Failures of an Entrepreneur: #1 Never Stop Selling
- First Year Failures of an Entrepreneur: #3 Getting Your Story Straight
When I started working on Treeveo during my MBA I was alone. Having no one to build the prototype, I decided to teach myself how to code and do it. The result was a system that worked and could be used by clients. It was however written in what engineers call “spaghetti code” and I designed the UI in PowerPoint. Needless to say there was much room for improvement.
After receiving our investment round, instead of doing a quick launch, we wanted to really re-design both the core of the system (in CodeIgniter) and the UI with a professional designer. Since then, we are constantly facing decisions on what to build, what to prioritize and perhaps more importantly.. what not to build.
When you are taking product decisions you basically have 3 sources of “input” to help guide your decisions. In a perfect world, those sources of input will give you a hint about what to develop. However, in a startup these sources are limited, so you are more likely to make mistakes. In our case we developed several features that weren’t a success. We also developed things that are loved by our clients. Here are the 3 sources that you could consider when constructing your world changing product.
Data: the obvious
If you work on product for a larger organization I assume you would have data at your disposition, sometimes even about millions of users. You can simply check user data to find clues on what functionalities you can de-activate to favor load time and usability. Alternatively you can use the user base to come up with new features and test their success. Running a B2B startup, we had very very limited user data. You could also seek out data from outside databases, about behavior, market trends or other relevant issues. In our case, as we are building a new kind of product, there isn’t really any data to look at.
Clients: the most desirable
In my opinion, the best place to get a hint about what to build are your (potential) clients. However when in a B2B start-up you have the disadvantage of not having masses of users to get data from. After a while we did get some clients that we could interact with intensively (which is an advantage of a B2B start-up). This allowed us to test features (through interviews etc) before building them. We avoided wasting resources this way (we didn’t build a mobile / table client for example). However sometimes clients don’t know what they want or need. As they always say: “Nobody said they needed an iPad”.
Intuition: when nothing else is available
When all else is lacking, you are left with your own intuition to decide on the next feature to develop. Your intuition as a CEO is one thing, but obviously we as a small team talked all together (engineering, sales, marketing). For example, one thing we developed was a 6Sigma module that allows clients to estimate the likely outcome of a project. We built this because I used it extensively in a project I managed in my previous career. However, in practice this feature wasn’t used very much. Other moments we built features that clients loved, like an extended export function with more visual highlights.
So how do you know what you should build? I would use the following prioritization to determine priorities: Data, Clients, Intuition. Perhaps that way you will be able to determine what your company’s equivalent of an “iPad” is (users don’t know they want it).
A final note: Follow your metrics, what you build for
When deciding on what to build, it’s also important to remember the metrics that are most important for your start-up. In our case it is revenue so we prioritize features that multiple clients ask for. In other cases your metric might be growing the user base, which could mean prioritizing for on-boarding for new users etc.
So remember before spending those super precious engineering hours: Be careful what you build for.
