This post is a constant work in progress and serve as a reminder to myself of principles to keep in mind.
First, define the goals and problems.
Do not jump straight to solutions.
The goal might be to create a better user experience or to help the business make more money, ideally both, but sometimes it’s a necessary short-term trade-off for long-term growth. What is the metric (and the counter metric) you’ll use to measure success?
Once you’re clear on the goal, what are the business or user challenges that prevent the team from hitting the goal?
This question will surface multiple problems,
Once you identify the problems, ask why these are problems and use the Five Whys to get to the root of each problem.
There will be a myriad of potential solutions to each problem, each with their own potential impact and effort and risk. Some of these will be good. Some bad. But these potential solutions will have more solid reasoning behind them than if you jumped straight to solutioning.
The point is: do not jump straight to solutions.
If someone jumps straight to solutions, help reframe the conversation and zoom out to what the problem is.
Determine risk, impact, confidence, and effort.
Adopted from Brandon Chu.
Every solution comes with different levels of risk, impact, confidence, and effort? Determining these won’t always be scientific but it helps to have a gut check on the potential projects to work on.
Risk isn’t about the risk of an experiment or a minimum viable product not succeeding. It’s about the context around the project. If the experiment fails, what is the risk that it presents? How would you define risk on a scale of 1-10, 10 being high risk?
For example:
- Testing copy on a website to improve conversions is low risk and easily reversible.
- Testing copy on a purchase flow is higher risk but still easily reversible.
- Testing a brand new purchase flow is high risk and potentially more difficult to reverse.
What is the potential positive impact of the project? Low or high?
On a scale of 1-10, how confident are you that it will succeed?
How much effort and investment will it take? How much scoping, design, and development will be needed to get the experiment up? If it succeeds, how much effort will be required to maintain it?
Be a director.
Adopted from Fareed Mosavat.
Think of your team as a really fast race car.
You and your team agree on the final destination and the only thing you control is the steering wheel. Your engineering team is the engine, moving the projects forward. Your designer is your co-pilot making sure that you’re hitting the right checkpoints and not going completely off the route toward the destination.
You should not be trying to change the oil (coding, reviewing all PRs, weighing in on technical decisions) or decide where the checkpoints (weighing in on all design decisions). Unless if those are areas where help or feedback are needed.
In some cases, jumping in might slow down the team. You might become the bottleneck.
In some cases, you might need to jump in because the team is stuck and you need to help them get unstuck. Read the room and know the difference.
Just don’t slow down the car.
Work with the team to align on the mission, point the team in the right direction, let them fly, and focus on keeping the team moving in the right direction. Keep your hands on the wheel.
Remind your team that they have decision-making power.
Adopted from Powerful by Patty McCord.
You do not need to be a part of every decision and, in some cases, you shouldn’t be. Your team is smart and capable. If the team is aligned on the mission, trust them to make decisions if you’re not around.
If it’s a decision you disagree with, have a conversation about it and understand why your team member believed that to be the best option to move forward. Just because you disagree or would’ve done it differently doesn’t mean it’s wrong. You might be missing some context or information and chances are things will work out.
Trust your team.
Get good at making hard decisions.
Adopted from Gibson Biddle.
For the decisions you should be making, just know it’ll be tough. It’s supposed to be tough.
Get comfortable making decisions without having 100% of the data because that will never happen. If you have 70% of the data, make a decision.
Get comfortable having challenging discussions where there isn’t a clear right or wrong decision, but there’s a decision to be made.
Get comfortable reversing your decision if the data later proves it to be the wrong decision. Hindsight is 20/20. It’s okay to be wrong, just make sure to fix it. Don’t let the possibility of being wrong paralyze you from making a decision.
Sometimes the best decision is the decision to take no action.
Get out of the way.
You don’t need to look at every PR. You don’t need to understand every bug. You don’t need to review every design. You don’t need to be part of every decision.
There are many things you don’t need to do.
Participating in these things generally makes you feel like you’ve done something productive, but I’ve spoken to numerous product managers who, at the end of a day realize they’ve spent time on things that didn’t help them move the team do better. Instead, that time was spent on things that didn’t actually need their attention.
There are exceptions to this principle, such as when you’re on a tight deadline and there’s a really important product to ship. In which case, yes you should be part of the details and moving the team along every step of the way.
Otherwise, don’t slow down the car.
Multiply your team’s value.
Adapted from Brandon Chu.
Work on things that’ll have the biggest impact, not just directly on customers but on the product and other teams.
If your team needs to build a library to support a new feature, other teams might find value in that library. Make it a reusable component that other teams can use.
If your team discovers a new insight about product usage, share it with other teams that would find it useful.
What is the 20% of projects you (and your team) should work on that would produce 80% of the results?
Focus on your unique contribution.
Do your best to focus on the high-value tasks that only you can do.
Automate the simple, repeatable tasks and delegate the tasks you’re not best suited to work on.
One example, I could design product mockups, but my designer would be able to come up with much better mocks in much less time and they’d probably have a better impact on the user experience.
In the case of a startup, you better be helping with all the tasks the team needs to complete to ship :)
Always be learning.
Learn for yourself, but most importantly on behalf of your team. Talk to other teams and departments. Understand what the marketing team is doing, what challenges the sales team has, what customer support runs into the post, what other product teams are building, what insights analysts have found in product usage and so on.
Bring relevant — or even not-so-relevant — insights back to your team. They might notice a detail or have a different angle of thinking about the insights that might lead to new ideas for your product.
Feedback on this is welcome as I refine my principles and communicate them.