Conf42 Platform Engineering 2024 - Online

- premiere 5PM GMT

Navigating the Developer's Journey: Crafting an Effective Roadmap for Success

Video size:

Abstract

Don’t miss this conference session for practical insights into crafting your developer roadmap. We’ll start by discussing pain points and exploring challenges developers encounter. Learn valuable strategies to work backward and propel your technical product forward.

Summary

Transcript

This transcript was autogenerated. To make changes, submit a PR.
Hello, everyone. Thank you for taking the time out of your day to be here. I'm delighted to be here today to talk about crafting an effective developer roadmap. This process is essential for ensuring that our development efforts are aligned with our business goals. and can effectively address the challenges our teams face. A little bit about myself. As a seasoned product manager, I have honed my skills in leading both front end and back end product development. Currently, I play a pivotal role at Bestech, a fintech firm, where I drive the product strategy for our communications division. I've also worked at firms such as AWS, where I orchestrated the product strategy for automating AWS infrastructure deployment. At Newmark, I headed their product department, successfully leading a website redesign on Microsoft Azure and establishing a dedicated team on customer centric product development. I also worked at Moody's, where I was head of deploying cloud data leaks on the AWS tech stack, enhancing ETL processes and data analytics capabilities. I'm also committed to fostering innovation. I actively serve as a board member, providing strategic direction and technical acumen to enhance the growth trajectory of a company by the name of Yieldwink's digital platform. We have a jam packed agenda, so let's get started. Let's get started. We'll start by understanding the fundamental importance of roadmaps. A roadmap serves as a strategic guide that outlines the direction and priorities for our development efforts. It's not just a plan, but a communication tool that aligns everyone in the organization, from stakeholders to developers, on what needs to be achieved and how we intend to get there. It's a product strategy. It's crucial to have a solid understanding. Of our business and organizational strategies. These strategies provide the foundation upon which we build our product plans. They help us understand the broader goals of the organization and ensure that our development efforts are contributing to these goals. Let me give you a concrete example. Suppose our company's overarching strategy is to increase revenue by 20 percent over the next year. Bye. For our product strategy, this means we need to align our development efforts with these revenue focus goals. We might prioritize building features that improve cross sell, up sell, like showing customers premium plans, or help with renewal probabilities. By aligning our product strategy with the company's revenue goals, we ensure that every piece of code written And every feature developed is a step towards achieving these broader business objectives. This alignment not only helps in achieving our revenue targets, but also ensures that our development efforts are recognized as valuable contributions to the company's success. Concepts of life. Let's take a practical case study. Our case study today focuses on a significant challenge. A made up company has been facing. They are a marketing led company, and communication in the form of emails is a very big revenue driver. But the business problem is, it takes too long for us to get email communications out to our customers. This delay in communication affects our business in several critical ways. Firstly, let's frame the problem clearly. The time it currently takes from conceptualizing an email campaign by our marketers to engineers actually delivering it to our customers is longer than we desire. This lag impacts our ability to respond quickly to market opportunities, customer feedback, and competitive pressures. It means that by time our emails reach our customers, the information might already be outdated, reducing its relevance and effectiveness. Now let's talk about the business value if we solve this problem. The faster we can get our email communications out, the quicker we can realize revenue or increase our monthly active users. In other words, reducing the time to value is crucial. This case study, framed by how might we statement, how might we deliver an email communication in under an hour, when given this problem. Will guide us through the process of identifying pain points, prioritizing them and developing actionable solutions. By addressing this challenge, we not only improve our operational efficiency, but also drive significant business outcomes. perform a current state assessment of our technology stack. We won't be going over technical details today, but just high level frameworks. For today's case study, we'll focus, we'll be focusing on reviewing a part of our marketing technology stack, focusing on the email communication process. This assessment involves a deep dive into our existing tools, processes, and capabilities, and how well they support our business outcomes. To get a comprehensive view, we interviewed different personas involved in this email communication workflow. These personas include marketers, engineers, and customer support representatives. To better understand the high level pains and needs within this process, we utilize the Jobs to be Done framework. This framework helps us focus on what each persona is trying to achieve, the obstacle they face, and the outcomes they desire. By framing our understanding around their jobs, we gain valuable insight into their key pain points and motivations. Analyzing the feedback from these interviews through the Jobs to be Done lens, we decided to focus on the engineers. Why engineers? Because they play a critical role in the development and deployment of the systems that enable faster dissemination of emails. By addressing the engineers pain points first, we can streamline the entire email delivery process. This will allow us to release email communications to customers more quickly. which directly supports our company's goals of increasing revenue. The clear understanding of our current state and the personas we're focusing on, we can now define our vision and success criteria. This vision acts as our target destination, while the success criteria provide measurable benchmarks to track our progress. Our vision is to enable the engineering team to deliver email communications to customers in under an hour. Achieving this will significantly improve our operational efficiency and align with our company's strategic goal of increasing revenue by facilitating quicker market responses and enhancing customer engagement. To set clear success criteria, we need to outline specific measurable goals that indicate progress towards our vision. These criteria might include what listed to your left. You might want to include reduction in email delivery time, which is decreasing the time it takes to deliver an email campaign from several days or weeks to under an hour. We might want to focus on increasing engineering productivity, enhancing system reliability, or focusing on stakeholder satisfaction. So increasing satisfaction levels among marketing and customer support teams by providing faster and more reliable email communication tools. Or we focus on none of the above or all of the above. Next, we have our how might me statement on the left. Walk through the developer journey and identify the pain points experience at each stage. At this stage, we list out the common engineering development journeys and ask them to list out all pain points based in these areas. As it relates to deploying an email communication. That is what in the middle of the screen. Next, The tool of choice here is Miro, but you can use whatever tool works for you and your team. The journey here includes requirements gathering. Here, engineers often face challenges like unclear requirements, changing priorities, and lack of stakeholder alignment. These issues can lead to significant delays and rework. Moving on to development. During development, pain points might include inadequate tooling, technical debt, and integration issues. These factors can hinder productivity and extend development cycles. Next, we have UAT or user acceptance testing. In this phase, engineers may encounter challenges like insufficient testing environments, poor test data quality, and limited feedback loops, all of which can delay deployment. You then have deployment. Deployment pain points often involve complex deployment processes, manual interventions, and configuration errors. These issues can lead to failed deployment times or failed deployments and increased downtime. And then we have monitoring. Post deployment monitoring can be hampered by inadequate monitoring tools, lack of real time alerts, and insufficient metrics. This makes it difficult to quickly identify and resolve issues. Identifying these pain points is crucial as it allows us to focus on the areas that need the most attention. Once we've listed the pain points, the next step is to vote on their severity. We take each sticky from the prior slide and categorize each pain point as high, medium, or low severity based on the impact it has on our ability to deliver email communication in under an hour. Remember to always tie it back to the problem we are solving. The voting process helps us prioritize the issues that have the most significant impact on our goals. So for example, a pain point like unclear requirements might be rated as high severity because it affects multiple stages of the development process. So how might we decrease time to value? Severity ratings, we then plot these pain points on a quadrant chart. But now the team will help us estimate how high or low the effort might be in solving some of these problems. The y axis represents impact and the x axis represents effort. This categorization helps us identify what on the top right quadrant Which is major wins. These are high impact and high effort. These are critical issues that require significant investment but will greatly benefit the project. What you see next to that is quick wins. High impact and low effort. These are the low hanging fruit that can be addressed quickly to yield immediate benefits. Below that we see fill ins. Low impact and low effort. These are the nice to have improvements that can be tackled when there's extra capacity. Next to that, we have money pits, low impact, high effort. They should be deprioritized as they consume resources without significant benefits. You'd be surprised at how many organizations have money pit items in their backlog and end the year with very low value delivered. Focusing on the high impact areas first ensures that we are making the most effective use of our resources. Now that we know what problems we need to solve, we can start our product discovery phase. In this phase, we focus on high level discovery without getting into the technical details yet. This involves brainstorming potential solutions and defining the scope of our initiatives. Here are the steps we typically follow during product discovery. Brainstorming solutions. Defining epics, clear acceptance criteria, prioritizing epics, and then creating a road map. Now let's double click on some of these. brainstorming solutions. We gather a diverse team of stakeholders, including engineering, product managers, and business analysts, to brainstorm possible solutions for the identified high impact pain points. This Creative approach ensures that we consider various perspectives and come up with innovative ideas. Finding epics. We then consolidate these ideas into high level epics. An epic is a large body of work that can be broken down into smaller tasks or user stories. For instance, if a major pain point may be the lack of a development testing environment, an epic might be establishment of developing testing environment. You then want to set acceptance criteria. For each EPIC, we define clear acceptance criteria. These criteria outline what success looks like for each EPIC and provide a way to measure whether the solution meets the desired outcomes. For example, the acceptance criteria for our established, the establishment of development testing environment a significant reduction in bugs and issues post deployment. And then we want to prioritize epics. After the finding the epics and their acceptance criteria, we prioritize them based on their impact and feasibility. This prioritization helps us focus on the most critical issues first, ensuring that we deliver maximum value as quickly as possible. And finally, we create a high level roadmap that outlines a sequence of epics we plan to tackle. This roadmap serves as a strategic plan that guides our development efforts over the next quarter or year. This roadmap is a living document, always subject to change as new challenges arise and priorities shift. However, it provides a structured plan that aligns our development efforts with our strategic goals. I always recommend using now next and later as the first presentation of the roadmap. While you start to flesh out the actual work this entails to provide accurate estimations of delivery. This product discovery phase is crucial because it ensures that we have a clear and actionable plan for addressing the high impact pain points first. By involving a diverse team in the brainstorming process and setting clear acceptance criteria, we can develop solutions that are both innovative and aligned with our strategic goals. Once our plan is finalized, the product manager can collaborate with the engineers to further refine the work details. Initially, we may focus on the minimum viable product or MVP version of the plan, ensuring it effectively addresses the problems and aligns with our business goals. On the right is an example timeline for breaking down the plan before we start writing our technical requirement documents and entering them into the backlog. From roadmap to backlog. Finally, the product manager translates these roadmap items into detailed product requirement documents. These documents are then used to create user stories that populate our backlog. This ensures that the development team has a clear, Prioritize list of tasks to work on. This process ensures that every user story is aligned with the overall strategic goals and addresses the critical pain points identified earlier. To summarize, we've explored the journey from identifying pain points to creating a detailed developer roadmap. By focusing on the most critical challenges first and developing actionable solutions, We can ensure that our development efforts are aligned with our business goals and deliver the maximum impact. This structured approach helps us navigate the complexities of software development and continuously improve our processes and outcomes. Thank you for your attention. I hope this session has provided you with valuable insights into creating an effective developer roadmap.
...

Ruby Kaur

Senior Director Product Manager @ Best Egg

Ruby Kaur's LinkedIn account



Awesome tech events for

Priority access to all content

Video hallway track

Community chat

Exclusive promotions and giveaways