5 steps to better product execution
Let your vision guide execution
Establishing a vision is one of those “bang for your buck” type tasks when it comes to product leadership. It isn’t always easy to do, but whether you’re leading a product organization, or a cross functional scrum team, a vision builds unity behind a common objective and if done well, gives team members motivation to execute, even (especially) when they run into roadblocks or other challenges.
Why is a vision necessary
When was the last time you went on a road trip without having a destination in mind? It happens, and it can be fun, but you’re more likely to end up somewhere that you didn’t intend, or worse, where you don’t want to be. You’ll end up with a history of roads that connect and don’t get you anywhere meaningful. In the world of software development, you have turned yourself into a feature factory. And even if you understand the destination as the product leader, those working on your team probably don’t. This leads to conflicting priorities, scope creep, and oftentimes wholesale roadmap changes in the middle of development, which can be frustrating for everyone. You’ll end up being at the mercy of those with a higher salary, louder voice, or who have built and communicated an alternate vision throughout the organization.
Building a product vision as a team will drive better and faster execution, and in a less expensive way than adding resources or training. Here’s how to do it:
- Create a vision
Start by interviewing key stakeholders, and reach high. Interview the CEO and other senior leadership. This is especially helpful if they are also the founders, since they know the original vision of what they set out to accomplish, and how that might have changed. Pay attention, not only to what they say, but how they say it. When they get excited…that’s when they’ve communicated their vision.
Interview customers. Understand the reason that they bought your product, and look to understand the problem that they’re trying to solve by using it. Without understanding customer pain points appropriately, a vision becomes little more than a roadmap. That doesn’t mean that we solve every customer problem, but we take those into account when creating a vision and strategy.
Create a draft of your vision. A vision is short, and inspiring. It should also be something that doesn’t make sense when viewed through the lens of another product, company, or team.
For example, consider Amazon’s vision statement: Our vision is to be earth’s most customer-centric company; to build a place where people can come to find and discover anything they might want to buy online.
It allows Amazon the latitude to buy and sell anything, and is unmistakably Amazon because it’s literally what they do. (It also wouldn’t make sense if Netflix tried to have similar language in their vision).
Similarly, the Tesla mission statement reads: Tesla’s vision statement is “to create the most compelling car company of the 21st century by driving the world’s transition to electric vehicles.” You can probably guess which company this belongs to without knowing beforehand that it’s Tesla.
Creating your own vision takes time. It should be inspiring, specific to your product or team, and also cast a wide net in terms of what you can accomplish while still aligning with your vision.
2. Let the team contribute to the vision
This is a critical step that’s often overlooked. Many product leaders view themselves as the ones identifying vision, strategy, roadmap, etc. And for the most part, that’s true. Scrum teams are often rotating, employees leave, and after all, it is the product manager’s job description to come up with those things. However, if you want the larger team to buy in, then you should include them in helping to create the vision.
After the product leader has taken a first pass, present it to the team. Encapsulate the “why,” explain the vision, strategy, and roadmap, and come with supporting data. Doing this helps the team understand and get behind the objectives. Don’t just leave it there though. If a scrum team wants to add a line around clean code, add it. If they want to change some wording to the vision, do it, or be prepared to explain why it should be left the way it is. Bottom line, the more input that they feel like they have into what the team is working on, the fewer conflicting priorities you’ll have, and the more you’ll see engineers taking ownership of the entire execution process.
3. Evangelize throughout the organization
If Martin Luther King Jr. gave his I have a dream speech to his close friends and those already inspired to help with the civil rights movement, would the impact have been the same? Of course not! Everyone should be aware of the vision, and how passionately the product leader believes in it. Share it with other leadership, with other teams, even those with whom you don’t work closely. They’ll become champions of the vision, and champions of you.
4. Focus
There are always competing priorities in the world of software development, this is especially true in early stage companies where a new contract may depend on functionality that hasn’t been built yet. Sticking to your guns can be difficult, and maybe not even appropriate. Many young companies have to change course in order to find product/market fit. Be flexible with your vision, and especially your strategy, but not so much you lose sight of what you set out to do. Remember, instead of trying to figure out a way to build a faster horse, Henry Ford built an automobile. His vision might have been something like, help people move faster. While that’s just an example of what it might have been, he was focused enough that he accomplished that vision through means that no one else had thought of.
5. Reflect
After you’ve put all of this time and effort into building a vision, strategy, and roadmap, who’s to say it was worth it, and that it worked at all. It isn’t always easy, but if the product leader believes in the vision, that’s what matters, since that’s who is ultimately responsible for delivery. Plus, if you believe in what you’re building, others will believe in it, too. And that’s what leads to faster execution. It doesn’t matter if it’s because there are fewer competing priorities, or engineers with magic fingers become magic-er. It just matters that there’s more output (and ideally, more, better outcomes).
After sharing a vision with a team I had the privilege of leading, along with the corresponding strategy, and roadmap. The senior QA member on the team stopped and said, “I’ll work as hard as I can to make this happen.” That attitude permeated throughout the entire team, and it did become reality. That reality is attributed to the character of every person on that team, and their desire to contribute, and buy into the vision that we were building towards.
One final note, if you don’t believe in your vision, no one else will. It’s the kind of thing that’s transparent. The vision that you create should align with your personal why, otherwise it’s just words on a page that won’t get traction and will soon be forgotten.
Take some time to identify your why, and if it’s something that aligns with the work that you’re currently doing. If not, it might be worth looking at other opportunities, especially given the current market. And if it is, great! Craft your vision, and work to make it a reality.