Winston, my co-founder, let me know the other day that he has started using our product to find sales leads. I was very pleased to hear this. You see, I’ve been of the opinion that as a startup we should always use the best tools available. I encourage this and work hard to research and provide the best tools for the team. To hear that Winston chose to use our product for a mission critical task, lead generation, is the best validation we have received to date. So yes I’m pretty pleased.
The benefits of being a user of your product are huge. You can start seeing it from your customers eyes. You can discover the rough edges and work flows that are cumbersome early on. You get fantastic feedback and ideas on the product. I don’t think anyone would argue that a startup shouldn’t use their own product.
The issue is how to get your startup using your product. There are 2 leading schools of thought.
The first is the scratch your own itch approach. In this model the startup is building a product that fills a need or desire that they have. The thinking is that the development team will be the first customers and users. That their passion for the product to exist will help them to create the best product possible.
This is an ideal situation. In my experience most startups don’t fall into the scratch your itch camp. Often they are building a product for a specific market. Or they may have started scratching their own itch but found their initial market too small. Regardless, I think that most startups don’t fall into this camp.
Which leads to the second approach: eat your own dog food. In this model the team is asked to use the product and provide feedback. In some extreme instances they may even be required to use the product instead of competing tools. The theory is that the team will discover problems and fix them early on. Or design new features that improve the product.
In practice this approach is disastrous. Since the product is often in its early stages, perhaps even incomplete, the productivity of the entire team is hurt. Team members start suggesting and lobbying for features that will make their job — not the customer’s — easier. Because team members have a horse in the race, more time is spent debating features that probably shouldn’t be there in the first place. And features get added in skunkworks projects, undocumented and hidden, to make one poor internal soul’s life a bit easier.
So I encourage the team to use the best tools possible. When they discover that what they are building is the best tool, that speaks volumes.