Most businesses start by being output-focused. The team is new, there's a lot to learn about the market, and you're still discovering what your customers need. It's easier at that stage to explore things with a set of simple activities (interviews, shipping core features, basic sales & marketing) and see what results from it.
But as your business grows, you'll see new friction points emerge. The bigger the team, the harder it will be to coordinate efforts. You'll need better ways to help everyone know what to focus on. That's usually when companies start to look into goal-setting to flip the approach around: spend most of your efforts outlining the desired outcomes, and then let people figure out how to get there.
There's a good reason why OKRs are so popular: they offer a simple framework to align your team and shift the focus from outputs to outcomes. But the problem is that you can't change your culture overnight and there are a few steps to go through.
|Stage 1||Stage 2||Stage 3||Stage 4|
|Focus on outputs||Outcome-driven||Outcome-driven||Outcome-driven|
|Top-down directives||Top-down directives||Top-down directives||Top-down directives|
|Bottom-up contributions||Bottom-up contributions|
The idea is not to prevent you from doing the jump to OKRs, but rather to make sure that you have the right habits in place to make OKRs (or any other form of goal-setting) successful. You can't simply ask your team to set some goals and consider it done — you'll need first to make focus and accountability an inherent part of your culture.
|Leadership controls||Leadership inspires|
|Top-down strategy||Bottom-up ownership|
|Passive contributors||Empowered teams|
|Producing deliverables||Delivering value|
|Siloed roadmaps||Shared North Star|
|Yearly targets||Quarterly goals|
Everybody wants to do meaningful work. But quite often, people don't know where to look to see the impact they're having. Don't ask your team to be customer-driven — they're busy solving complex problems. Instead, you should blend customer feedback within your workflows. Luckily there are a few low-hanging fruits that can help.
It's much easier to do things than to explain why we're doing them. Writing a vision document is an excellent exercise for the leadership team as it will force them to outline their thinking. And once it exists, it becomes a reference point for every debate. Is this piece of work helping with the vision? Yes: 👍. No: better come up with a good reason to do it.
Simplicity brings clarity, so no need to write a lengthy document. I'd recommend having the following.
Your vision document should be easily accessible by all, and you'll need to show it often. It'll feel like a boring reminder but your team will forget the top priorities unless you put it back in front of them every month (it's not that they don't care, it's that they're busy solving problems).
(We also wrote a post on our framework)
Team kick-offs are a great way to get everyone on the same page at the beginning of a project. Get your Product Managers to write a short draft outlining the problem and user stories. Then get the product team together (Design, Dev, QA) to discuss the project:
The goal of team kick-offs is to share ownership of the project. The earlier you do that, the easier handovers will be since people are already familiar with the plan.
You can increase engagement by adopting the concept of Feature Leads. Rather than getting the Tech Lead to own the relationship with the stakeholders and the technical direction, you ask a developer to take care of it for a specific project or feature.
They will be the main point of contact for a particular piece of work, but they're also expected to seek help and feedback. Introducing Feature Leads is a great step forward to increase autonomy and give more responsibility to the team.
Move away from "it's released" as the definition of done by adding success metrics to your specs. It'll bring the conversation back to what matters: how the work you do can lead to a better experience. Is the goal to reduce customer support? Increase the activation rate? Introduce a new capability?
Having to think about impact, and not just the complexity of a piece of work will also help put things in perspective. It'll push the team to think about the tradeoffs they're making as they're planning their work. It's easier to avoid costly efforts if you know you'll have a small pay-off.
Demos should be a weekly ritual bringing the team together to celebrate progress. A good habit is to start every demo by stating the Why. It's a small thing that can prevent rabbit holes.
For your website, is it worth implementing a full A/B test if you don't have much traffic? For your MVP, should you already be moving to Kubernetes if you haven't had a single use of your product yet? Those examples may look extreme but it's not rare to get lured into increasing the scope unknowingly. Talking about the Why helps us define the right boundaries.
Most of a demo meeting should be about progress on deliverables. You make sure that things are heading in the right direction, identify blockers, and sync up on what everyone has been up to. 90% of the time allocated should be about outputs.
But you should reserve 10% of the meeting to talk about outcomes. What are the goals for the team? How far are we from achieving them? 10% of a 30 minutes session means spending just 3 minutes on a slide that shows how the needle is moving. But if you put those 3 minutes at the end, then outcomes will be the one thing on everyone's mind at the end of the meeting.
Get technical folks to join in on customer interviews. PMs and UXers should still drive the conversation, but having devs listening in has a lot of benefits:
Customer feedback should be readily accessible to the team, and you should share it with them as much as possible. Link your NPS surveys to a feedback channel on Slack and relay quotes that you get via email or support tickets.
Don't see this as an opportunity to chastized your team with negative comments. The goal is to boost morale and show folks how they're making an impact. Find the right balance to give a sense of purpose while also challenging the status quo.
Here's one exercise that I guarantee will shake your team to the core: record a testing session of a user onboarding your product. Make sure you get the sound on and that you can see their face while they click around. Then watch the recording together as a team.
There's nothing more effective to get rid of hubris and help everyone on the team realize that they are a power user of the product. You'll cringe together, but you'll come out of it humble and ready to fix things. Repeat this exercise often and you'll see the mindset shift slowly from churning out features to seeking feedback after a project is released.
Last but not least, retrospectives are a fantastic tool for transparency and accountability. It helps people slow down to figure out how to improve. It allows the soft voices on the team to be heard. It minimizes the risk of recency bias by bringing up the timeline of events.
But more importantly, retrospectives are about letting the team decide how they can get better together. Embrace that tool to empower your teams and give them autonomy.
"What got you here won't get you there" - Marshall Gold
Here's a story that I've heard many times over. Someone is hired as the first Product Manager to streamline the product strategy. But, fast forward a few months, and the CEO is still dictating every bit of the roadmap.
- Yes, yes, you own the roadmap. - Ok then w— - But we need to do <insert project> first. - That's a good idea bu— - And then <insert project> is critical too. - We hav— - <current project> should also be done like [step-by-step execution plan]. - ...
It's not rare that a company that got great success in its early days finds it hard to change the culture as it grows. If the business thrived thanks to the leaders being hands-on then it will be hard for them to step back. It will take time and intentional effort to build the trust necessary for handovers to happen. But it's an essential investment to move to the next stage.
You don't hire great people to tell them what to do — you hire them so they can show you how it's done.
For the founders: give some room to your team. They might not pick the same path as you would, but there are many ways to get to great results. For the new team members: ask for a progressive handover of responsibilities (aka reduce your expectations) and show to the leadership team that you understand their concerns.
The bigger picture might be clear in your head, but it won't matter if no one else can see it. You'll need to outline the vision clearly in a concise document that is easily accessible by the team. Another advantage of having a vision document is that it removes misunderstandings. You might not get everyone to agree, but it will at least be possible to disagree and commit.
Here's a simple template to create a vision doc:
You must have a unique purpose, and I would suggest only 2-3 focus areas and 2-3 measures per focus area. The fewer items you have in your plan, the bigger impact you can have on each of the priorities.
Here's what it looks like for Tability:
Last but not least, keep a keynote slide version of that doc and put it in front of the team every month. It's easy to forget long-term outcomes when you have hundreds of emails and dozens of meetings every week.
Also don't hesitate to review and refine your plan as you learn more about your market and customers — it should be a living document, not something set in stone!
Hey 😅 this chapter is not finished yet but we're working on it!
If you're interested and want to follow updates you can: