Agile Product Management — Sharon Ikechi
Sharon Ikechi is a product manager that collaborates with teams to build products and experiences that provide value to people. She is also passionate about leveraging technology to curate innovative learning experiences for developing talent. She has worked on products in Edtech and Fintech and is currently doing amazing stuff at Symply.
What is Agile Product Management?
To explain Agile Product Management, let’s start with what product management is all about. It’s about working with teams to build the right product in the right way. (let’s break this down further)
- The right product — The product meets the needs of the client, and the client is happy with the product.
- The right way — The software conforms to a specific design and the design satisfies the stated requirement.
It seems very straight forward right? However, Software product development teams are often faced with complex projects that are prone to risks, complexities, and changes in requirements over time.
A step-by-step approach in building products, which is known as the waterfall model, defines requirements upfront and delivers projects in sequential phases, but it is vulnerable to failure if requirements change later in the development process. Customers want products to be continuously improved with new functionality. And remember, the customer has to be happy with the product. So the question is how can we increase customer satisfaction by working closely with and incorporating feedback from customers throughout the development process?
This is where Agile product management comes into play. Agile product management involves setting up flexible processes that allow the development team to build products in small increments and infrequent releases so the team can respond quickly to changes. And that flexible process/approach/mindset is the Agile methodology.
What are the benefits of agile product management? What’s the value in involving customers and incorporating their feedback quickly into the product development process?
In summary, the value lies in making your customers happy/satisfied with the product and making money for the business.
But I’ll break this down as well into these 7 benefits:
- Respond quickly to new and changing requirements. The Agile methodology is set up such that you are constantly inspecting work done and making changes to the product as fast as possible.
- Start delivering value to customers early. We all know the competitive nature of businesses, and the need to retain existing customers and acquire new customers. With Agile, you start delivering value to customers and keep making updates as you go along.
- Adds value to the business by achieving better results or building better software
- Reduces the risk of building products that do not meet the needs of the customers, or the goals of the sales & marketing team
- You can build according to your own schedule and resource availability
- It supports collaboration among cross-functional teams like engineering, design, sales, marketing, customer support, operations, data, etc
- You’ll get to learn from your customers :)
What Agile software development methodology do you recommend and why?
So Agile Software methodologies provide frameworks on how you can adopt Agile in your team. It defines the process for collaboration. For example Scrum, Kanban, Lean, XP, etc
And I’ll always recommend an Agile methodology that works best for the team. It might be one method or a combination of methods. This is because no two agile software development teams are the same. As teams mature, you’ll find out that current processes no longer fit and would have to be adjusted to re-align with the team.
And so, as an Agile product manager, you should have some knowledge of each methodology to determine which one is best for the team and the product life cycle at that particular time.
But let’s look at this from a data-driven perspective. According to the State of Agile Report 2020,
- 95% of software organizations practice Agile development methods
- Scrum remains the most common Agile framework used
- Accelerating software delivery and enhancing the ability to manage changing priorities are the top reasons stated for adopting Agile
This means Scrum is one skill you’ll want to have as a product manager. I love Scrum because its framework can be applied in so many ways, and it just has a way of bringing clarity into complex projects. I think Scrum is also simple to learn and apply.
However, take note of this, don’t get stuck on applying the methodologies without being realistic. Even the scrum framework as it is does not apply to all teams. As you work on more projects, you’ll get better at being a practical Agile product manager/scrum master, and start applying scrum in a way that works for the team. I’m still learning how to do this :)
What are the core Product management responsibilities carried out in an Agile environment?
I think these make up the core responsibilities carried out by an Agile Product Manager:
- Understand customers' needs: I usually have client calls twice a week, during each client call, I speak with about two clients, so I can understand their perception about the product as well as their needs. Then I generate insights from their responses which feeds into the product strategy.
- Set product strategy: Your product vision, goals, and initiatives should be determined by the user research carried out. If it’s a B2B product, when you begin to see a pattern in the responses from a certain industry, you might want to start paying more attention to that industry and include them in the product direction.
- Create the Product Roadmap: As an Agile PM, you are responsible for creating and updating the product roadmap throughout the product lifecycle. An updated roadmap provides direction to the development team and gives insights to external teams like marketing and customer support.
- Prioritize features: In an Agile world, the PM has to constantly decide what to build and when. So don’t get too attached to a feature, it’s more about what the customer wants than what the team wants to build. Factors like customer feedback, market trends, business goals are part of the prioritization process.
- Measure & Communicate product success: Identify the relevant metrics to be tracked, based on the business and product goals. Business metrics give insight into marketing, sales, revenue, and growth, such as conversions, churn, Customer Acquisition Cost (CAC), etc. Product metrics give insight into your user's behavior, such as Active users (daily, weekly, monthly), Net Promoter Score, etc. Measure and communicate these metrics to the development team, as well as external teams.
How can you make everyone in your company become agile enough to deliver the best?
When I joined Symply, the goal of the software team was to boost productivity through weekly releases. I spent my first 6 weeks creating an Agile (Scrum) Process for the team. And here’s how I achieved this:
- Ask the team what they want: Don’t assume. If it’s a small team, speak to each member of the team and find out what their current challenges are with regards to development processes and team collaboration. You can also ask about what’s going well within the team.
- Create an Agile process that works for the team: It may be scrum, or kanban, or scrumban. But the goal here is that the team should be able to adopt the Agile process without hindering their productivity.
- Obtain feedback from the team: Reach out to the team to find out what they think about the agile process. With their feedback, you’ll know what needs to be removed or improved in the process.
- Support the team in adopting Agile: Provide some sort of training or learning resources for your team to level up on Agile. For your developers, they should be familiar with agile development practices like pair programming, TDD, CI/CD, etc.
- Align on the team and business goals: From time to time check that everyone in the team knows how the agile process enables the team to achieve the team goals and business goals.
After the discussion session, we had questions from the members of the community, here are some of them.
How do Agile frameworks work in a small startup? Say you have just one/two engineers, a designer, and a PM.
The Agile framework helps with this by creating specific roles. Generally here’s what the roles look like according to the framework:
- Product Manager: Owns the product strategy and roadmap and determines what to build.
- Scrum Master / Agile Project Manager: Responsible for managing the software project and coaching the team in agile practices.
- Development Team: The team often includes skills such as design, development, testing, and delivery.
- Stakeholders: This includes a broad category of people, such as end-users, executives, IT, operations, portfolio managers, and support.
Now, say you have just one/two engineers, a designer, and a PM, here is what the roles may look like: Development team: 2 Engineers, 1 designer&Product Manager. I’ll assume there is a CTO/CEO in the company as well, the person can be part of the stakeholders/development team. For very small teams, pay particular attention to the goal of the team. If the goal is rapid development, working in sprints will be great. Maybe 2 weeks or 1-week sprint. At the start of the sprint, the PM outlines what stories will be developed, the team agrees and development starts. At the end of the sprint, the team reviews what was developed, and if the team agrees it meets the stated agreement, it’s pushed to production. I think on a very high level that's how it works.
Could you please paint scenarios where the waterfall method and agile method are used? That could help with understanding the differences.
The Agile method: An Edtech company needs to launch a product in August that teaches kids how to code. The software team has just been formed. Research is still being carried out on the market survey, however, the team is ready to start working on the system design while research is ongoing. The designer will start working on designs next week when the user stories are ready. This is a typical example of what a complex project looks like. Nothing is almost certain but one certain thing is that the goal is to launch in August.
The Waterfall method: The team needs to work on an enhancement for one of their features. It may or may not require research to be carried out, but the team is very clear on what needs to be added or removed, and so the tasks go from one stage to another — design to development to testing-launch
How do you decide on whether to use Kanban, Scrum, or Scrumban?. Does it depend on the company, does it depend on the product or the goals?
What is the determining factor to adopt a particular Agile process?
It depends on a number of factors, and you already mentioned some of them.
- The goal of the software team
- The nature/complexity of the product
- The resources available
When you think about adopting an Agile process, break it down into these three areas:
- Communication & Collaboration: What are the team's structure? What tools will be used for communication? How will the team collaborate?
- Work Allocation & Estimation: How will work be communicated with the team and shared among the team?
- Risk & Quality Management: What test method will be used?
Let’s say you just join a company as a PM, and you are given the task of creating an Agile process for your team, you can start by asking the team these questions:
- What is the team’s current structure? (number of devs, location, overlap hours, etc)
- What project management software tools are being used?
- How is work allocated & estimated for each member of the team? How often does everyone meet as a team?
- How is a quality check carried out on the team’s output?
- How are the customer’s requirements obtained and communicated with the team?
- What are the current productivity challenges faced by the team?
- What does the team hope to achieve from an improved process?
In trying to ensure that applications deployed suit customer changing needs using Agile methodologies, how can a PM balance respond to changing requirements and also ensuring that the company’s interest is also taken care of? For example, a software company builds applications for a business that requested for ‘A’, documents were signed off, payment made, timelines given, and then in relating with the company on the progress of the development, they bring ‘A+’ which stylishly enters ‘B’ which is now beyond the scope of the initial request. Does Agile Product management have ways in handling such knowing that its core is to adapt to changing requirements that could be beyond the scope of the initial request?
Okay, so even though you are adopting Agile as a process, you’ll still want to reduce risks as much as possible. If you encounter the situation you mentioned. I’ll say you need to create an internal pipeline for the software & product team. Now this pipeline isn't just for the software team which is the usual — (planning, in progress, review, done). It's a pipeline that connects the software team with the customer support team (I’m assuming now that the customer support team is responsible for discussions/back and forths with the client). The pipeline should be transparent so everyone that's a part of it knows what should be done at each stage. Including the client. And it can look like this — (requirement gathering -> sign off -> payment made -> timelines given -> proof of concept sent -> development starts)Now what this does is that it gives everyone time to make changes at each stage because an official review and handoff take place before you move from one stage to another. So by the time the tasks/requirements get to the development team, it has been through series of steps where clarity was requested for. For example, if you send the client a proof of concept which may be like a database design or something, for them to approve, it means you’ve done something right.
Now moving to development, have in mind that the client will still review iterations of the product and give feedback, but in this case, it shouldn’t be like having to start from scratch. And if it requires having to start from scratch, well we live in a complex world, so don’t be too hard on yourself
