Embracing Outcome-Oriented Development Practices | John's Tips 2024W35
Explore my shift from feature-focused to outcome-oriented development. Learn how to enhance collaboration, efficiency, and customer satisfaction with practical insights from how I am accomplishing it
This blog touches on a popular topic in the product development world: shifting a teams’ approach or framework from a “feature team” to an “outcome-oriented” team. Both approaches or frameworks have upsides and downsides, and should be considered based on the projects, products, or organizational landscape.
As a product manager, it is important to choose the approach that best aligns with your needs. As an engineer, it is important to understand the many ways you can influence roadmaps and foster this collaboration with your product manager counterparts.
Throughout the course of this blog, I’ll summarize the differences between what it means to be a “feature team” and an “outcome-oriented team”, as well as my recent endeavors in shifting my new team to an outcome-oriented approach.
At a high level, a feature team, also known as a delivery or output focused team, is primarily tasked with developing specific functionalities within a product to meet short-term project goals and deadlines. These teams could be described as a dedicated group within a product development environment that focuses specifically on the development of distinct features. This approach often emphasizes rapid delivery and feature completion, driven by a clearly defined list of requirements or a tight deadline.
An outcome-oriented team, also known as a value-driven team, could be described as a dedicated group that prioritizes the broader impact and value these features bring to customers and the business. Outcome-oriented teams aim to understand and measure how their work affects user satisfaction and aligns with strategic business goals.
Adopting an outcome-oriented approach
Why am I shifting our team approach?
Adopting an outcome-oriented approach promotes broader ownership and fosters an inclusive environment where every team member's contributions are pivotal. Our engineers, developers, QA, and many others play a crucial role in contributing their technical expertise, deep knowledge, and innovative solutions.
By enabling each team member to champion solutions - referred to as our 'Epic Champions' - we empower them to take active roles in our projects ensuring that our solutions are both technically robust and aligned with our strategic business priorities.
My goal is for my team to spend more time on the things that deliver value to customers, and less time on the things a good ticketing workflow automation should be able to achieve.
Through this we aim to enhance product robustness, sustainability, and overall shift our team’s focus from delivering features to creating impactful solutions. This methodology directly benefits engineers I’m partnering with by providing them with opportunities to enhance their leadership skills, dive deep into new technical areas, and apply their unique expertise to critical challenges.
Such participation not only drives project success but also accelerates personal and professional growth, making this approach particularly valuable in a tech-driven environment.
What could you expect to see if you did this shift?
Shifting to an outcome-oriented approach can bring about significant benefits for teams and their organization as a whole. Here’s what you might expect to see from this transition:
Increased Efficiency: By focusing on outcomes rather than just outputs, your team can prioritize work that directly contributes to business goals. This can lead to reduced time on less impactful activities and a quicker realization of business value.
Enhanced Collaboration: An outcome-oriented approach requires collaboration across all technical and non-technical disciplines, significantly enhancing integration and cohesion within engineering teams. This strategic collaboration not only improves communication but also ensures that engineering efforts are fully aligned with the broader business objectives, leading to more technically robust and business-aligned solutions.
Higher Customer Satisfaction: With a focus on outcomes that matter to your team’s customers, you can expect to see an improvement in customer satisfaction. Your team’s work will be more closely tied to addressing customer needs and solving their problems.
Improved Adaptability: Outcome-oriented teams are typically more flexible and responsive to changes in the market or customer preferences. This adaptability can be crucial in staying competitive and innovative.
Greater Employee Engagement and Morale: Employees tend to feel more engaged and satisfied when they see the real-world impact of their work. By emphasizing outcomes, you can help team members understand how their efforts contribute to the company’s success, which can boost morale and reduce turnover.
Clearer Metrics for Success: Adopting an outcome-oriented model provides precise success metrics, directly linking them to specific engineering outputs and customer satisfaction. This enhanced clarity not only boosts accountability within the engineering team but also focuses efforts on impactful innovation and operational improvements, encouraging precise and effective engineering practices that align closely with customer needs.
These expected results highlight how the shift to an outcome-oriented approach can drive significant improvements across key areas of operations and team dynamics.
How am I doing it?
Using processes I have learned, studied, and implemented in the past, my team will adopt agile methodologies to enhance flexibility and responsiveness, utilize data-driven decision making to align projects more closely with business outcomes, and employ cross-functional collaboration sessions to ensure that every team member can contribute to and understand the impacts of their work.
While in the early stages, my team has already started this shift to fostering an outcome-oriented culture in a department whose main customer stakeholder personas are internal and working directly with or supporting our vast and diverse customer base.
We have identified our main stakeholder personas, have outcomes and are already delivering towards them for a number of our current projects (using this guide 😉) , and have broken down the problem space into understandable chunks.
This guide gives you an idea of what my discovery and delivery process looks like, and you’ll see more in that series soon. I’m just working out the final kinks in my Jira Discovery board at the moment, but I feel like it won’t be long before that will be ready to share.
What do you need to make this shift on your teams?
It is important to know that this involves more than just a shift in tasks; it requires a fundamental change in mindset by the people joining your team, as well as the support structure surrounding it.
If you’re interested or considering making a similar shift within your teams, here are a few things I’ve learned along the way that aid in this shift.
Step 1: Get Started Checklist
Buy-in from your manager/department/company. Connect with your stakeholders, manager, peers, and leaders and explore solutions that fit best. Every company is different, and this is not going to be a one-size-fits-all solution.
Strong documentation & diagramming skills. If you are trying to introduce new processes, and you expect people to follow them, having visuals and documentation is key. I’ve included two template examples below to help get started.
Product operations skills. Having a solid foundation in product operations will help a lot. Familiarize yourself with key processes such as agile methodologies, utilize template documentation for consistency, and explore automations to streamline tasks. Consider finding a mentor with expertise in product operations to help accelerate your learning and application of these skills. (I’m available on ADPList if anyone wants to chat)
An abundance of patience. Change takes time, and depending on the project could take months to years. It depends on a multitude of variables, including (but not limited to): the size of your company, willingness to change, how far from Outcome-Oriented development the existing processes are currently, and more!
Continuous Discovery Habits. Embracing the principles outlined in this concept can provide valuable insights and best practices for shifting to an outcome-oriented approach. Familiarizing yourself with continuous discovery techniques will help ensure that your projects remain aligned with user needs and business goals. I highly recommend reading Continuous Discovery Habits by
Step 2: Identify and Understand the Existing Discovery and Delivery Process
Exploration / Discovery
The next step in your journey to shifting to an outcome-oriented approach is to do your own discovery into your current product development process. This includes everything from high-priority year-long initiatives, to tech debt sitting in the backlog. One way to do this is to treat your overall project way of working just like any other major development project.
Spend time discovering what the current customer journey is (customers meaning your engineering team), identifying the pain points, and diagramming the current intake, discovery, and delivery process for all work that the team might take on.
Creating a way of working guide like the one I mentioned on this template is a good place to spend some focus time with your team. It won’t be perfect for your company, but that’s fine, you just need a starting point and some direction.
The product discovery and delivery processes the team or company are already following were originally created for a reason. Many of these reasons are still valid and important to stakeholders, and you’ll need to cater for them in your new process. Remember, if you don’t understand the current state, it’s going to be a lot harder to guide your teams to the ideal state!
Documentation Example 1
Here’s a sample diagram you can use to outline the current product development process. Simply change the values below to the way your company works. We use T1/T2/T3 to designate the priorities in our department, but in other companies this may be P0/P1/P2, t-shirt sizing, or big rocks/pebbles etc. The naming doesn’t really matter, its the structure tied to those names that count. The names might change, but the essence is still the same. Projects of different sizes will have different requirements and also different release practices.
Documentation Example 2
Here is another sample diagram you can use to identify what must-haves should be included in each project in your discovery document templates based on the Priority the project has been assigned to. This will give your team a good baseline for building your own templates going forward, while also not leaving out anything that is critical for the company.
At this stage, it’s helpful to connect with your peers. Consider asking “Can you share the projects you feel had the biggest impact?”
The best question that worked for me though, was:
“Can you send me documentation for the projects you are most proud of?”
The responses you’ll get to this are likely the projects your peers and leaders feel strongest about, so if you can bake a template with ingredients from all these different projects and implement that as part of our delivery process, you are more likely to ensure that our approaches are comprehensive and robust, enhancing buy-in across the board.
Conclusion
All of these pieces of information add up and form the most important first step in your journey - discovering how your company’s product development process works. Laying the right groundwork is crucial to set your project up for success moving forward.
I am looking forward to sharing more about the tools, strategies, and insights learned in future blogs as I continue to refine our approach and implement these changes. My team’s journey toward adopting outcome-oriented practices is just beginning, and I am excited to reveal the outcomes, best practices, and lessons learned along the way.
For More Tips
I have a lot of other content on this website you might find useful. Simply check out the headers for the subsections of interest.
For my past tips check out my past posts on Substack or check out the hashtag #JohnsTipOfTheWeek on LinkedIn.
I’d love if you subscribed! I’m trying to build a bit of a following to try and help folks in the industry and make their jobs a little bit easier.