This blog post is the first of an ongoing series of engineering leadership topics.
Product and engineering teams are a match made in heaven, but often siloed within organizations. This is especially true for larger organizations with teams of many product and engineering professionals. There may be intersections at points of the product/delivery lifecycle, but unification between the teams from product inception to production release remains rare.
In order to unlock the true potential of your organization’s product and development success, I believe it is imperative to unify both teams and eliminate any silos that exist. I’ve seen this work and drive success across many organizations. This blog will outline a high-level blueprint to facilitate this winning strategy.
Leaders and Managers
Let me begin by saying there is a distinct difference between leaders and managers. They are not mutually exclusive; in other words, a leader can be a manager and vice-versa. However, both roles have significant differences.
One way to think about this is that leaders are responsible for everything externally facing with respect to the team. For example, organizational vision, company values, instilling motivation and buy-in for moving the organization towards the future. This can be accomplished by determining how the organization is different and what differentiates them in the market. It’s usually communicated well via a vision statement.
On the other hand, managers are responsible for setting expectations with their teams and ensuring they are understood (by using both verbal and written communication). It’s also critical for managers to keep their team accountable by measurement and providing constant feedback. Good managers will do this by empowering their teams to take ownership and action to accomplish goals.
Unite the Teams!
Once leadership has outlined the vision of the organization, it’s time for Product to start laying the foundation and creating the right tools and features objectives to move forward and accomplish goals. I highlight ‘objectives’ here because, in my opinion, this is the first mistake organizations make. Most of the time, ideas for tools and features that are developed by Product alone are usually flawed. An alternative approach is to think about the actual objective or the problem to be solved first.
In order to realize the full value of your engineering team and the value of an individual engineer, their work should start at the point in the lifecycle when objectives are being defined. Here are the reasons why I think this is important:
- Engineers are intelligent. If you relegate their responsibilities to being heads down and coding based on feature/story requirements, you’re not getting the most value from them. They can bring many ideas to the table and help vet and refine the objectives. If your organization utilizes engineers like they are putting together parts on an assembly line, you’re leaving a lot of value on the table.
- By having your engineering team work with Product to define the objectives early in the process, they feel more included and aligned with the vision. This empowers individuals and allows them to contribute to taking the organization to the next level. This is very powerful and can go a long way.
- When the engineering team is brought in later in the process, there are typically a lot of questions about the objectives, requirements, and issues that are trying to be solved. If they are involved at the start of the process, there will be less time wasted on these types of discussions.
I frequently hear leaders say, “We want to be the best team at the company” or “Our company will provide better experience than the competition”. This is a great start, but I immediately ask these questions:
- “What does that actually mean?”
- “How can you measure it?”
- “How are you tracking progress against these goals?”
I often don’t receive good answers to these types of questions. I can’t emphasize enough how important it is to have quantifiable goals and the ability to track progress made for each goal. One great way of enabling this is using the Objective and Key Results (OKR) framework.
The idea behind this framework is to define goals and then assign specific key results associated with each goal. The key results must be quantifiable, otherwise it’s futile trying to track progress against the goals. Here are a few examples of what an OKR would look like:
- Objective: Increase user retention for Epic App
- Key Result: Average session duration up by 15%
- Key Result: Time on page metrics up by 20%
- Key Result: Net Promoter Score (NPS) increase by 5%
- Objective: Improve user acquisition for Epic App
- Key Result: Increase active users by 10%
- Key Result: Attain 10,000 customer orders
- Key Result: Raise conversation rate to 20%
Building a Roadmap
Once clear and measurable objectives have been established, it’s time to start building out a roadmap for delivery. One important question to ask is, “How do I know what to add to my roadmap?” This is where the relationship of Product and Engineering works nicely. The engineering team can start building out Minimum Viable Products (MVPs) that align with each objective. For example, if the folks from both teams think a new feature would increase user retention for the Epic App, a lean MVP should be built quickly and deployed to customers to receive immediate feedback. If that given MVP starts gaining traction and receives good feedback, it can be added to the backlog to refine and improve over iterative versions. If the feature does not get positive feedback, it’s time to abandon that idea and move on to something else. Another way of thinking about this is failing fast and developing lean application MVPs. Always seek out feedback from users or customers of your product before you put in too much work to a feature or tool bound to fail. High performing engineering teams should be able to work on multiple MVPs at the same time.
Once a roadmap has been built out with user/customer validated features, it’s time for your managers to push the engineering team into high gear. Whether your organization is using Scrum or Kanban, ensure the following tasks are met:
- Timebox and set deadlines for all your stories or features.
- Document expectations around delivery and ensure they are understood by the entire team.
- Empower team members to solve and complete features by giving them autonomy and freedom to come up with solutions.
- Measure performance results (this can start with delivery metrics like burndown rate and cycle time to more specific. development/DevOps metrics like testing coverage and lead time).
- Hold the team and members accountable.
- Encourage and reward for excellent performance.
A quick note on a product delivery framework called pirate metrics that I believe provides a lot of value. It’s based off an acronym called AARRR.
- Acquisition – drives customers to your app
- Activation – measures use or conversions of the app
- Retention – are people staying and using the app?
- Referral – do users enjoy the app and refer other people to it?
- Revenue – can the app drive revenue?
The details and implementation of this framework are outside the scope of this blog, but essentially, it provides a set of metrics where product and engineering teams can measure and target work to develop a successful product. I’ve seen teams focus on certain metrics for a given time interval and use each metric as a basis for building MVPs and acquiring user feedback. It provides a framework for driving success based on vision and business objectives.
For more information check out this link.
Most organizations don’t realize the full value of unifying both product and engineering teams. In order to be high performing with product and software delivery, it’s critical to leverage the most value from all your team members. Begin by making iterative changes outlined in this blueprint and you’ll be on your way to realizing epic teams and software.
Learn more about how Xpirit can help you transform your business here!
Follow me on Twitter here!