Not only is it hard to attract talent to your startup (know any free developers in the Bay Area?), as a founder you also have to set the proper structure. A common saying is that you need a “Hacker, Hustler, and a Hipster” on the founding team. In the earliest days that makes sense, especially when you are MVPing and hustling for your first customers trying to find a product-market fit.
Sometime after you have product-market fit and raise a round of funding, you need to hire outside of the core founding team. A lot of founders struggle with the right roles to hire and what the proper structure should be. Some founders hire too many engineers (typically non-technical founders) and some founders hire too many “business” or “marketing” people (typically technical founders), leading to being lopsided in one area. Founders run the risk of being engineering centric or marketing centric in their product development. In reality they need to be customer centric and embrace the Holy Trinity of Product Development.
The Holy Trinity of Product Development: Dev Lead, PM, PMM
When it comes to product development, you need three distinct roles. Those roles are what I call the Holy Trinity of Product Development: Developer Lead, Program Manager (PM), and Product Marketing Manager (PMM). These three roles work together to represent the customer and build the business, ensuring that you are not too engineering focused or too marketing focused. The role in the middle of that fine line is the Program Manager.
Program Manager (PM)
What is amazing about the PM is that they have no power or authority over the PMM or dev lead, all they can do is influence the engeneering and marketing teams. It takes a unique skill set to get this done.
The dev lead has a difficult role to play insofar as they have to represent the engineering team to the PM and PMM as well as work on all of the “tech stuff.” The tech stuff includes: setting the development architecture, get their DevOps game on by organizing the build (doing things like Continuous Integration and Continuous Deployment), coding, and choosing the right technology for the job (Rails or PhP anyone?) The dev lead also needs to keep the engineering team together and motivated and make sure that the agile process is, well, agile.
The hardest part of the dev lead’s job is interfacing with the PM and PMM. The nature of startups is that they are resource constrained and always in a rush to get something shipped. That means an insane amount of pressure on the engineering team. It is the dev lead’s responsibility to work with the business (PM and PMM) in order to set realistic deadlines and proper expectations, all while not being the guy complaining about lack of resources. Not always an easy task..
Product Marketing Manager
While the dev lead represents the engineers and the PM represents the customer, the PMM represents the business. While the PMM is responsible for what all non-marketing people think of as marketing (ad campaigns, trade show booths, email blasts, product placement, media placement, etc), they are also responsible for the business model of the product and making sure that the product makes money (or reaches its broader goals if it is a loss leader.) This means setting pricing, and if this is a freemium product, that is far more complex than you can ever imagine. The PMM is ultimately accountable for the product making money.
The Right Balance
Some startups and companies are tempted to combine the PM and PMM role. This is bad! What happens when you combine these roles is that the focus usually becomes either too customer centric or too marketing centric; you need two people and two distinct roles to prevent this from happening. The right structure creates the right environment. The right people in the wrong structure is a waste of talent, they will not be able to use all of their talents, they will spend too much time fighting the incorrect structure. No amount of free massages, free lunches, and unlimited cookies will fix an improper structure. (Actually it is Google, Facebook, Linkedin, etc who have pioneered the Holy Trinity in Silicon Valley. They adapted it from the larger tech companies such as Microsoft in the 1990s.)
The right people in the right structure/environment is where the magic happens.
This may sound like a lot of overhead, however, you are probably doing this in some form already. Typically at the early stage, founders take on these roles and hire people to pass them off to. It’s a sign that your startup has matured and left the experimental phase.
Now go and build awesome products!
There is no consensus on company culture, so some companies do not even pretend to have one. Their mission statements are “achieve US$1 billion in market value by 2020” or “maintain sales growth of 20% per year”. In addition to being a failure of the imagination, this approach is unlikely to achieve even these narrow definitions of success precisely because of the lack of culture.
There are more companies with relatively inspiring official mission statements such as “innovation for a better future” and “making the world healthier”. These are complemented by statements of values, such as “Respect, Integrity, Communication and Excellence“. However, as Enron proved spectacularly, this is not enough.
The reality is that organizational culture is not created by the slogans on a website or giant posters hanging on office walls. Culture is created by everyday habits.
Why are habits so important? Our memories are actually not very good. Of course, they can be trained over time: repeat to remember. But to really have an impact, memories need to change behaviour, and that means habits.
Habits are simple ideas but messy in reality. For example, the idea of curiosity. Many companies would benefit by having more curiosity as a core value. But how would you turn curiosity into a habit, a true value, rather than simply an empty statement?
First, start with a small win. For example, Friday Pizza Questions, a Friday afternoon pizza session when people can sit down and ask interesting questions. No answers, just questions. Over time, you will build up a list of questions and start to notice patterns. In addition, people will get into a habit of asking questions just for the sake of asking questions. They will start to ask more questions during the week. Build from there.
Friday Pizza Questions contains the three core elements of a habit cycle:
1. Trigger / cue: Friday afternoon
2. Routine: ask a question
3. Reward: mmm, pizza
Most importantly to build a lasting habit, you then have to repeat until it is automatic.
Having an inspiring mission statement is a starting point to build a successful culture, but mission and values must also align with habits. Start small, then repeat and grow.
One of the worst parts of investing in early stage companies is saying no. A lot. We say no more than 100 times for every 1 yes.
Since our investment philosophy is people first, some assume that people are our only filter. They believe yes means we like the team and no means we don’t like the team. But that’s not the case. We also need to have conviction about the business and market plus of course need to be comfortable with the deal structure. As a result, there are many times when we say no even though we like the team a lot. That’s not fun for the team, or for us.
So why do we bother to give a clear no? Why not simply hang around on the sidelines with a maybe? Especially since it’s probably better for us, just in case the deal becomes hot and we can jump in at the last second.
Because that’s not fair to the team. We hear too many stories of investors playing games with entrepreneurs, resulting in wasted time. In addition to being fair with time allocation, we also try to be clear with feedback and give specifics of why we are saying no. If we have done serious work on the opportunity, by definition it means that we have been impressed by the team, and so we try to make this feedback useful for them. Once again, too many investors give a one line no, without any context for the decision.
Although there are no short term benefits for saying no clearly, we strongly believe that there are long term benefits for us by taking this approach. Great teams appreciate clear feedback, good or bad. When teams are doing due diligence on us, they inevitably speak to others who have received a no from us and how we act in these situations is a reflection of our overall approach. Great teams are smart enough to appreciate the connection.
So, even though it’s no fun for anyone, we will continue to say no a lot. Even to teams we like. Knowing that it’s the right thing to do for them and for us.