“At Y Combinator, we see a lot of companies who raise money on demo day as you can imagine, but still the vast majority of them die and about 70% of them do not go on to find any form of product market fit. Here are the most common trends”
Michael Seibel
I found an online talk by Michael Seibel here (https://www.youtube.com/watch?v=Dgmmje5WHWA) that described literally every issue I have encountered since starting. It is the most relevant and useful advice I have seen in a long time. I wrote them down and organized the content into something people can skim and google easily.
Basically, your ability to get features, iterations, and bugs out the door starts slowing and slowing and slowing. So now you are taking fewer shots on goal. This is a way I see startups post-seed round die constantly.
Causes
You have no process for deciding what to build.
No Process.
You don’t run sprints.
You don’t have deadlines.
You don’t write specs.
You just have conversations and then build what you talked about. You don’t write anything down.
Your engineers are not involved in product decisions.
The people who are doing the work are not involved in the discussion of what should be built.
No metrics.
You can’t tell whether products working or not because you’re not measuring anything.
You stopped interacting with customers.
You got too busy. I’m too busy doing these other things, I can’t talk to my customers anymore.
Bad co-founder relationship.
If the team is not motivated, product development slows down.
Low quality product founders.
I call these people fake Steve Jobs. They are the people who believe they know what the customer wants without ever talking to them.
Low quality technical founders
Your technical founders are not strong enough to produce product at high enough quality quickly. Very typically, this happens with outsourced engineering teams.
Signs
Deadlines are always missed.
Or there are no deadlines.
Your release schedule is quarterly or longer.
You can’t get anything out in less than three months.
Discouraged or disengaged engineering team.
An engineering team that doesn’t care whether you’re winning or losing.
Half done features piling up.
This is commonly the cause of a bad product founder. They will have the team running down one road to build this thing, then some customer will say something or they’ll have some new idea. Now they are cutting that project short, not releasing it, andr running down a different road. Very bad.
Preventative Measures
Have a product development cycle.
If you google search “Michael Seibel product development cycle” you’ll see an example of one that I’ve used. (I will include that at the bottom of the this post.) You can have any cycle you want, just have a cycle and a process for deciding what you build that is repeatable.
Understand that one optimization you need to do is having a process where you take as many shots on goal as possible.
As opposed to having a process where you try to imagineer what’s the perfect shot next.
Always be collecting qualitative and quantitative feedback.
You should always be in whatever your analytics product is. You should always be doing user interviews.
Write specs.
A product meeting is not done until there’s a written spec that everyone can look at.
Use product management software.
By the way, none of these things are that crazy. It is just that people always make excuses for not doing the basic things.
Have the product brainstorm with everyone.
Even if everyone’s not contributing equally. Have everyone in the room when you’re deciding what to make. Especially when your team is small – under eight people or so.
Give all team members access to the customer and access to the customer data.
It shouldn’t be just the product person that’s doing user interviews. It shouldn’t be just the product person who is in Mixpanel or Amplitude looking at the stats.
Understand that motivation is a multiplier effect on talent.
More often, I see the product lead or the CEO not managing the motivation of their team. They think they know what needs to be built. They think they have the right people. But because they’re not managing those people’s motivation, all progress slows.
Understanding that whoever’s leading product is responsible for making sure that product is released.
Not deciding what to build. Everyone can contribute to the conversation about what to build. Your responsibility is to make sure that when we say we’re going to build something, we build it. When we say we’re going to build it, we have a deadline that we hit. Your responsibility is making sure the product development process is working. You’re going to have some ideas that will get built, but other people should have ideas that should be built too.
Michael Seibel’s Product Development Cycle
Your product development cycle should have enough structure so that you/your team can look back and understand what your goals were, what your core assumptions were, whether you accomplished your goals, and what you learned. The easiest way to do this is to write things down.
Michael has an article here: https://www.ycombinator.com/library/4e-product-development-cycle-fundamentals
Define Your Development Cycle Length
Your development cycle should be dictated by your product.
Determine Your Goal(s) and Identify the Product Lead
Whichever goal we chose would be the focus of the meeting and, therefore, the next two weeks.
Organized and Inclusive Brainstorm
Everyone was expected to contribute. Debates or putting down other people’s ideas wasn’t permitted.
Building a Consensus
We would start with the hard ideas–it was easy to form consensus because we knew we could only do one and because we knew that we would start a new dev cycle in two weeks.
Clear Spec and Clear Measurements of Success
We would also spec the stats we needed to track in order to measure how effective the feature was. We would never release a feature without releasing the analytics for that feature and understanding what specific measurable result we wanted to create.
Working During the Development Cycle
During the last three days of every development cycle, we would all stop building and test. We had a testing list in Excel that included manual tests for all of our basic functionality. Everyone on the team tested.