Our guest
David Pereira, co-author of Agile Product Manifesto and a recognized Product Leader with more than 15 years of experience. David loves to share his valuable product knowledge through Linkedin, online articles, product coaching, and various workshops. You can learn more about David on his website https://d-pereira.com/work-with-me/.
Listen to this episode
Transcript
Gosia: Hi, I’m Gosia from Whiteboards and this is the Agile on Board Show. Today, my guest is David Pereira, recognized Product Coach and co-author of Agile Product Manifesto. Hi David, thank you so much for accepting the invitation to the show.
David: Hi, thank you for having me here.
Gosia: Thanks for being here. Today we’re going to focus on the prevalent issue, namely how to escape the feature factory.
First, can you help us understand how to recognize that the team is working in the feature factory and then how to escape it?
David: One of the first things is to look at the amount of output you’ve oriented your decisions to.
- What kind of conversations do you have?
- Do you talk about what to achieve or what to deliver?
- Do you care about meeting deadlines or reaching goals, key results?
One of the aspects that can easily identify if you’re in a feature factory is the size of your product backlog.
If you see more than 100 items, generally it’s a sign of that.
If items stay in the backlog for a while, more than six months, even years, this is something that sounds like a feature factory.
The other aspect is the roadmap. Is the roadmap defined by goals or features? How is the team involved in creating the roadmap? These are signs that you are in a feature factory.
Gosia: It’s feature-driven and basically every Sprint you’re delivering a feature and it’s just focusing on the output.
David: Another sign is-it’s a question I like asking-when was the last time you removed the feature from the product? It’s generally the case that many teams keep adding, adding, adding features, but they don’t spend any time removing them.
It’s kind of a mindset that a great product is the one you have nothing else to add. I think this is actually incorrect. A great product is one, you have nothing else to remove. This is the mindset.
If you keep adding features, it’s a sign that you are not measuring the results because for sure some features are not going to work.
Gosia: Do you have some advice? If the team is focused on delivering a particular feature, any specific questions that the team should focus on before deciding if this is going to provide value?
How to approach this? How to decide, and prioritize if this feature should be included?
David: The first thing is understanding what the feature is for. Many times we just develop features for the sake of developing. This is an issue because if you don’t know the problem you’re trying to solve, most probably you’re not going to solve it.
The first thing is to ask, “If we get this feature live, what is the result we expect to achieve?” How does that make the lives of end users better and how does that contribute to the business result? Let’s understand that. What does success look like?
Try elaborating on these questions and then you can see how this feature connects to the goal we are pursuing at this moment. If you don’t have the goal, try connecting it to the vision. It will be a little bit more complicated, but see how this helps reach our vision. And if it doesn’t, why would you bother?
Gosia: Would you say that you can change the mindset maybe in the team, the product team, but if the stakeholders are not on board? How to change their mindset? Should it come first from the stakeholders, this change of mindset on how we’re developing the product and providing more value? Can it come from the product team and influence the stakeholders? Is it possible?
David: First the product team needs to develop this mindset. You need to have a problem-solver mindset and you can only solve problems if you understand them. Then you need to educate the stakeholders, which is quite hard.
It will depend a lot on the culture you are in, but one of the things I like doing is giving them an example, that stakeholders are most probably not the end users. They enable the product team to create value for the end users and if stakeholders know the problems, they should bring the problem to us, not the solution. Most of the time people think of solutions.
I always give the same example. When you go to the doctor with a stomach ache. Do you come to the doctor and say, “I came here for you to prescribe me this medicine or maybe I want you to operate on my stomach?”
The doctor just looks at you and says, “Okay just hold on for a minute, what’s happening? Tell me the symptoms.” Then this person says that they had a stomach ache for two days and the doctor asks , “What did you eat?” The doctor will start investigating the problem sphere.
What we need to do is to help stakeholders move to the problem sphere and then as a specialist-because we are the doctors-we can come up with the solution. This is one thing that I tried doing, helping them step into the problem sphere.
Gosia: And this can help change the mindset, focusing on the problem.
Is it more about listening to the customers and understanding their problems and then testing? Right? Does this involve more risks then? Would it result in failing and then learning faster?
David: It will result in failures.
The other approach of delivering features will also result in failures, but it will take a while to realize that. Once you realize this, it will be too late to react. The loss is already too big if you have invested time to get a feature live in your product.
But if you are in the problem space, it means that you are going to test because you have many assumptions. You say, “I assume that they care about this, let’s try providing a remedy for that, let’s try providing something.”
Then you try something and you realize it doesn’t work and say, “Okay, so it’s not worth investing time here, let’s try something different.”
The idea is to make small investments as often as possible to test your idea. Pay attention to what I say-test your idea not validate-because many people think they need to validate their idea and this is a little bit of a trap already. If you try to validate, you look for the positive all the time and you need to go there with a curious mindset. You can say that you want to falsify your idea to prove you wrong. Just say you need to test it.
Keep an open mind and be curious to understand what works and what doesn’t because for sure there will be things that just don’t work. In reality 9 out of 10 ideas will fail. That’s why you should drop the nine bad ideas as fast as possible to find a good one.
Gosia: And this probably creates innovation, right? Faster learning.
Can you tell us also how success is measured? When we focus on outputs, it’s so much easier to measure success and when we escape the feature factory, how do we actually measure the success with outcomes?
David: The output is easy to fool us. We can celebrate velocity, we increased velocity by 10% and say, “Wow, that’s it!” We increase velocity, more features, and so on, and then forget what for.
It’s true, outcome requires more ownership and it’s more challenging and it’s full of traps as well.
A mistake would be to say, “The outcome is more revenue or even worse, more profitability.”
Why is it a problem saying that? It’s too late to measure the revenue if you say, “I want to ensure to increase revenue by 10% by the end of Q2.” Only by the end of Q2, you can understand if you have increased that or not. Of course, you can forecast the steps but still, revenue is a laggard metric.
A lot of things need to happen for you to be able to measure revenue and the outcome is more oriented to what your feature contributes to.
If you take an online shop as an example, let’s imagine you are improving the search result.
You realize that you have a lot of, ‘no results’ and you want to improve that by giving something that customers may want.
What you want to measure first is the number of people that click on the product after searching for something. That’s what you want to increase first because that is a leading metric.
If people click on the product most probably they will add it to the cart. The very first step is clicking on the product. You want to improve that step and then you can improve the next and the next and so on.
Look at something that is a leading metric.
If the ultimate metric is revenue, you can ask, “What would lead to revenue?” Then compose that into some other aspects that you can measure and this would be the outcome.
Gosia: To focus on smaller goals if we have this huge goal, just to focus on smaller steps and it’s so much easier probably to plan as well?
David: Exactly.
Gosia: Thank you so much David for joining us and explaining this to our audience.
Thanks, everyone for watching this episode of Agile on Board. Tune into our future episodes and let us know if there are any specific topics that you would like us to cover. See you next time! Bye.
