It’s been quite a while since I’ve had time to post here…but I can explain!!
For the past 8 months, aside from my standard fare of corporate finance and macroeconomics classes, I’ve been spending much of my time outside of work a building a web-based product, as well as the business requirements that developing and releasing a new product entail.
What I’ve been building with a partner is an enterprise software suite. I’ll get into greater detail in future posts (breaking Chris Dixon’s recommendation for being un-secretive), but I’m primarily interested in talking about what I learned, rather than the product iteself.
To sum up my recent experience, we had an idea for a tweak on an enterprise software suite. We had a philosophy, and approach, to the user experience that was pretty unique from what everyone else in the space was doing. We were confident that there was a market need and that it was not being addressed. So, in August, 2009 a partner and I started building our solution. Fast forward today– we were beat to market last week by a major player in the space.
I want to share two key items I’ve learned from my experience to any entrepreneurs out there:
Don’t over-think it: Share your ideas and get feedback. You really need to take ideas out of a vacuum as soon as humanly possible; to get in front of people and talk about your idea. I learned so much from people who weren”t anywhere near the industry that our product was being bult to service. Why? If you cant explain what it does quickly and clearly, you have no idea what it does and you should stop what you’re doing. This goes for functionality and value proposition. Even if your product is insanely complicated, the value proposition should be clear and simple.
Get to market at (almost) all costs You can never build anything in your garage that will be better, or even as good, as what an existing competitor can develop. All you get to be is first. The benefits of first-mover advantage are debatable, especially when network effects come into play. Being market ready is not a function of having every feature complete and bug-free, it’s about having it good enough to get people using it, and allowing it to change dynamically. I’ve recently enjoyed reading posts and editorials from the 37 signals team. I think they have a lot of smart things to say about the dev process.
That’s about it. We’re still moving along and the product is still great, but if I could repeat the process, we would have dropped features and gotten it out quickly.
Dont be overly-precious with your ideas. Involve people early and change as you go.
More to come.