I have covered a couple of topics in this series, the first being hiring the best people and the second organizing for success based on the attributes of the people you are hiring.
Today I want to go into territory less obvious because let’s face it, hiring the best people and creating conditions where they can succeed is the kind of startup advice that is squarely in the “stating the obvious” category. This next one is also obvious but has so much nuance that it deserves attention.
3) It all starts with the product: Companies can overcome a great many challenges with band-aids, duct tape, and bailing wire. but one aspect of a startup and/or growth stage company that cannot be glossed over is the product. It all starts with the product. Marketing and sales will be amplified with the right product or victimized by the product that falls short, and not investment outside of product will overcome that reality.
Putting forward the right product for the market is absolutely key, but don’t confuse that with putting forward the BEST product. Ultimately you need to achieve best in class but if you try to achieve that in the first iteration you will be hopelessly late. and more on point is that the best product is a result of what you learn from your customers, not what you think you should be doing.
If we did anything egregiously wrong at Get Satisfaction in the 2010-1012 time period it was to under-invest in the product with the assumption that the existing product was good enough. The early architecture conditions created what engineers called “technical debt” and that effectively became weaponized to stall significant investment in fixing the old in order to build the future. Compounding the problem is that we became victim of agile engineering in a poorly structured development organization where there were no clear teams focused on building to the user archetypes and investing in the platform.. engineers paired would jump from frontend to backend erratically at each sprint iteration.
We failed to accommodate the changing demands that are a result of market, competitive and customer dynamics, all of which conspire to put you at a competitive disadvantage when you don’t have a market footprint that legitimately reclassifies you as a platform instead of just a product. Feature development is a result of the demands of the biggest customers with the loudest voices, the platform evolves at the rate which new customer features are required, not anticipated mind you, and lastly the API development is focused on what internal developers require rather than what the partner ecosystem is asking for.
In the absence of an org structure that creates a constructive tension between the product management and product engineering sides of the house engineers will work on things that are interesting to engineers but fail to advance the business. This is where we really erred in our approach, engineering and product management all report up to the CTO, and the company fundamentally underinvested in product management as a functional area.
In all fairness, the fact that the underlying product architecture was constraining product development had to be dealt with because in order to build better product their needed to be a foundational renovation of the substructure, and after years of kicking that can it was finally addressed in 2012. With that in mind I can’t help but remain conflicted by my view on this, either we replaced the architecture and built little in the way of new product or we focused on cobbling together new functional features that satisfied immediate demands while potentially sacrificing long term gains. and by framing it as a binary choice I am perpetuating the problem in many ways. We should have been able to do both.
My experience at Get Satisfaction has left me with a strong appreciation for the role of product manager, which as many in Silicon Valley will point out is the most powerful role in any company. While true, this oversimplifies the challenge of the role, which is not to wield an autocratic sense of control over product direction but rather be an effective consolidator of many sources of information, from all corners of the company. Good product managers hold dear a narrative about the market that is rationalized with the realities of running the business and they are always a half step ahead of the rest of the company in bringing product capability to bear that is great than the sum of a bunch of features. Lastly, a foundational skill of great product managers is GSD.
(Cross-posted @ Venture Chronicles)
Startups Lessons: Product First is copyrighted by Jeff Nolan. If you are reading this outside your feed reader, you are likely witnessing illegal content theft.
Enterprise Irregulars is sponsored by Salesforce.com and Workday.