Typically, when there are signs that the product isn't doing well, stakeholders start evaluating all the players on the board. Your team looks at dipping KPIs quarter after quarter. The whole organization starts to feel pressure from stakeholders, yet no one knows what to do about it.
Having been on several web3 startup teams, I can quickly understand whether the problem is the process or the team. Here are a few things I have learned to spot along the way.
No Accountability
Too often, I have seen little management within organizations. Product Managers set goals and timelines; however, nothing happens when those timelines lapse. When teams spend countless resources on a feature that similarly does not get results, no one is at fault. Teams are allowed to produce whenever and whatever they want without any consequence.
How this looks IRL
"When will this be done?"
"We are doing all we can to ship sometime within the few weeks."
Notice how the respondent didn't give any tangible timeline.
"How did we do this quarter on customer acquisition?"
"We got X amount of users but right now market conditions are poor and this is affecting results" OR
"We saw a bump in post views, which means users are interested in this product."
Notice how the respondent shifts focus to a metric that wasn't the defining success metric or shifts blame to external circumstances.
How to Fix
Managers
If you are a product/design manager, talk to team members in a 1-1 setting. Set tangible goals for your team members. These should be output bases since it should be your role as a leader to ensure the project your team works on directly impacts company KPIs.
Builders
If you are a product designer or engineer, work with your managers to aid them in adequately scoping work and implementing a more rigorous project management platform that is task-based vs project-based.
Having set tasks assigned to members gives the team clear expectations weekly and makes tracking projects easier.
Emphasis on Output
Startups are often working with a limited set of resources. Whether they are just now generating revenue or still heavily dependent on funding, every dollar counts. I often see teams heavily valuing the output of each team member. Output culture often manifests as pressure on product teams to ship as many things as possible in a week. These teams don't evaluate whether the projects are high quality or have any effect on organization KPIs.
Output-based cultures end up with very disjointed product experiences. The teams see little engagement with each of the features shipped. A common conclusion these teams come to is assuming that if they advertised the features more, customers would adopt the tools created.
The lack of research, testing, and regular engagement with users for shipping results in increasingly unusable products, putting teams even further away from product market fit.
How this looks IRL
"What did you ship this week?"
"Yay, we shipped four things this week."
"Do we know what these features will do for a customer?"
"Yeah! Tons of users want to do X."
Notice how the respondent didn't outline the strategy around the feature they are shipping.
How to Fix
Ideally, before a feature is shipped, there is at least a loose feature spec that answers these fundamental questions.
What is the feature?
Why build this?
What information do you have to indicate that this is the right approach?
What is the cost of building vs the potential growth?
Few Opportunities to Reflect
When you are in a culture that values output vs outcomes, there are very few team conversations about the results of the features shipped. Lack of reflection can look like feeling satisfied with what was accomplished without any growth or improved KPI to show for it.
There is no problem with shipping a lot of products. However, it becomes an issue when your team is sinking many resources into solving problems your users ultimately don't find valuable.
How this looks IRL
"We shipped five big features this quarter! It was tough for the team, but we feel great about our work."
"Do we know how well X feature performed ultimately?"
"We saw a slight bump in engagement, and marketing drove some conversion.
Notice how the respondents don't know precisely how their features have affected the organization's goals. They also have provided no insight into any learnings from their shipped features and how that has informed their future work.
How to Fix
Assign a leader and build in set timelines for reflection for each item the team ships. Giving owners to initiatives lets your builders own the features and products they ship. They can leverage the findings from each feature in future projects.
Lack of Self Awareness
As product builders, we all have our own biases. We want our products to do well. We strive for growth. However, it's easy to forget that our customers don't think about us as much as we think about them.
I have seen teams often have an inward approach to product building. Lack of awareness often looks like this:
Not keeping track of the market trends in their industry
Little competitive analysis
Minimal understanding of their users
No research/testing outside of power users
A lack of understanding of how your products fit within the lives of the people you target typically results in a continued output of out-of-touch features. The organization will start to see a significant drop-off in user acquisition funnels. The marketing budget increases to slow down the rate of churn.
How to Fix
Set aside some resources to contact a highly trained user research professional. Conducting targeted research will allow you to understand how best to connect with your users and expand the organization's view on user behavior.
I especially recommend hiring for this role because teams in this culture that do their research ask the wrong questions. If your team has never done research, it is easy to churn out lousy research.
The worse thing than no research is BAD research.
Adversion to Standards
Startups have to be scrappy. When you depend on funding, you have no time for bloated processes and meeting hours. I do believe in what I like to call the Minimum Viable Process. The issue with a team that is a people problem vs a process problem is a pushback or aversion to any process.
Adversion to Standard looks like managers attempting to create project manager processes like a roadmap or ticket system. Then, a few months later, no one is using that process anymore.
Cycle
Projects Hard to Keep Track of -> Team Creates New Process -> Team uses a process for a limited time -> Projects start to lag ->
If your team is having trouble keeping a semblance of process to ensure projects are shipping on time and having an impact, then your team may have an overall issue of accountability.
How to Fix
Unfortunately, if a team constantly pushes back on any standard, you may have to consider restructuring your organization. To begin troubleshooting, closely observe where the team's pushback is coming from.
Building successful products is highly dependent on the team you onboard. Often, cultural issues arise when hiring foundations lack rigor. When hiring, I challenge stakeholders and hiring managers to look at these key core attributes.
Trust: Can you trust this person to retain integrity even when there is nothing to gain?
Competitive: Does this person want to win? How have they handled losses?
Culture: What does our company value? Does this person align with those values?
Outcome-Oriented: How has this person affected outcomes in the past? How do they reflect on past work?