Proudly brought to you in association with S A Partners, a world-leading business transformation consultancy.
Introduction
Welcome to Episode 41 of the Enterprise Excellence Podcast. It is such a pleasure to have Mr Vasco Duarte on the show with us today. Vasco helps small and medium-sized companies generate customer-centric products and get their processes to a level of performance they thought was impossible. Vasco does this by focusing product development teams on the end-to-end life-cycle of their products. From Concept to Cash and Back!
Vasco is the Author of the book "No Estimates" and daily podcast host at the Scrum Master Toolbox. Vaso gives back to the community every day to improve the IT and product industry worldwide. Let's get into the episode, Vasco thank you for joining us today.
Summary
From sceptic to convert
Vasco started as a software engineer and quickly realised that most of the problems in product development were actually due to process and people's problems rather than technology problems. So he tried to help by becoming a project manager. The way Vasco discovered Scrum is a funny story. His company was doing a pilot, and Vasco wanted to prove that young kids don't understand product development and that project management works. So don't mess around with this Scrum thing! Vasco led the pilot by the book. Then, a few months into that, he discovered that not only did it work, but it worked much better than the mental models of his project management times. And he never looked back. From sceptic to convert.
Vasco had been reading a lot about Lean and began to put everything together once he had seen it in action. Lean, and specifically repeatable processes, are the core of improvement. Lean is also a people-centric approach to manufacturing. Scrum is a small kernel of a much bigger system: the agile method, which is about continuous improvement and focusing on how people interact. Vasco began to transpose lean improvement ideas via Scrum into product and software development.
Vasco's career evolved. He worked for many years to produce or develop ID products, software products, typically, and sometimes hardware. And after a while, he saw the same problems occurring over and over again. He was fed up with making other people's mistakes and became a consultant to make his own mistakes and learn from them. Fast forward almost ten years after that decision. Vasco realised that many things that he was applying to other people's products he could also apply to his own.
Creating his own products
For example, the 'Scrum Master Toolbox' podcast, run by Vasco. He started with the idea of creating a very simple, very focused, but daily production of content for Scrum masters to help them. He began by applying the Lean principles he already knew, and after a while, the process became a part of his regular work. Consulting followed, and Vasco took the lead from Mike Rother and Toyota Kata, helping others learn. What he did for others, he made a conscious change to do for himself, to control his own time and actions. It is all inter-connected for Vasco. He believes that Scrum, when poorly applied, deviates from Toyota Kata, but when correctly used, it merges with the process of the Toyota Kata. Toyota Kata also builds on the work by Short and Deming, through the PDCA or PDSA cycle: plan, do, check or study, act.
Importance of a goal
Ideally, actions occur in small increments within the context of the goal. First, learning happens, and then small improvements arise as you continue to reach that goal. Vasco believes that Toyota Kata forces us to clarify the theory that drives our actions and that learning is driven by the end state (the goal).
Unfortunately, many Scrum masters today still forget about that critical tool: to set a sprint goal, and sadly, lead their teams astray. They turn their teams into a ticket handling machine. How many tickets do we need to handle this week? And the ticket number becomes the goal. This detracts from the ability to learn because there's no possibility of learning if there's no end state. Teams should have a goal, and importantly, they should also have a theory of how the world works to improve how they work. Not having a goal stops learning. The team becomes a machine tackling the backlog items rather than collaborating on improving the company's outcomes or product they are trying to develop.
So, what is the right work to produce? And even if it is right, is it still the right one to do now? If there's no understanding of where we're going, any work is good, right? As Yogi Bear used to say, if you don't know where you're going, anyway will take you there!
Product owners can get better outcomes by engaging with sales.
Vasco is training product owners to start with their customer's vision for the product, rather than their own or their company's vision. One of the advantages that product owners get from engaging with sales teams is hearing their customers language.
The wrong type of interaction - sales led development without the why
Vasco talks about interactions between salespeople and product owners. The wrong type of interaction is when a salesperson says, "Here's the list of features you need to develop for my customers".
The right type of interaction - collaboration and engagement
The salesperson could be a great source of insight for the product owner. Great product owners will engage the salesperson to understand the context around that list of features: why are they being requested?
Salespeople have an incredible mindset in intuitively understanding the customer's business model. Vasco believes that when a product owner can tap into this mindset, they can amplify the customer's business model. But, unfortunately, the majority of the products out there are a burden on customers. They impose tasks or models on the customer rather than help them succeed.
So for Vasco, what's most important about that engagement between product owners and salespeople is when the product owner understands why salespeople repeatedly bring in certain features. They begin to understand the customer's language. Product owners should use that customer language in defining the vision and goal of the product solution for customers rather than purely delving into the solution. The product owner and development team should align their actions to the voice of the customer, and the salesperson is the key to the voice of the customer. When they collaborate, a better outcome is achieved for the customer.
Vasco encourages asking the questions:
What has my product done for my customer?
How do I make my customer succeed?
How do I make them feel awesome?
Salespeople and product owners do not have the answers to these questions, but their customers do. But only when you show them a mock-up, a video demos, click dummies and understand is this solving a real problem? Then develop the feature. Don't do it the other way around. Understand the deeper reason that a customer wants a feature. Run a test with your customer to explore the solution ideas before validating product ideas.
MVP and MVE
MVP stands for minimum viable product. Great product managers and product owners understand that it's actually an MVE: a minimum viable experiment, something you deliver with the intent of learning more about the customer's problem.
He gives an example: if you don't work with salespeople, whatever you come up with as the MVP, it's a shot in the dark. You shoot, but you never know if you hit the target. But if you work with salespeople, your minimum viable experiment is a way to fish for feedback to learn if what you thought might be a solution will work. So instead of spending six to 12 months figuring out the whole feature set that you then go and sell and it doesn't sell, you would create small iterations in short sprints. The saleperson shows them to the customer and gives feedback to build a better product.
The Superman role
Product owners are like Superman, as they embody the CEO job, the marketing job, the product management job and the sales job. It's a high responsibility and challenging job for someone to play. If they consider involving the salespeople and collaborating with them, they may perform at a more acceptable level as a product owner.
Example of collaboration between product and sales teams
Vasco worked on a project for about one and a half years that was being developed from scratch. The team started with a very clear definition of who the customer was and what they were trying to achieve. They were wrong when they started, but that's okay; they needed to start somewhere. And then, they engaged directly with business development to visit customers directly, engage with them, and listen to the problems and business goals they had. And together with business development, they began to understand the business model they were trying to enable for the customer: to help the customer make more money. The only way they could succeed was to involve business development and salespeople in those conversations.
Together the team created a product that went from zero to 10 million in less than four years. And the only reason they did was that the salespeople believed in the product and wanted to sell it.
What stops collaboration between sales and product owners?
Product owners live in a different world than the salesperson. Vasco believes that salespeople are always frantic about the next thing to do, the next customer to visit, and the next deal to close. They don't have time to spend two, three days talking to product owners about product vision. Product owners can do something about that by engaging with the sales work, going with the salesperson to a customer, and listening. And as trust builds with that salesperson, the product owner can ask questions after the meeting. And then, later on, perhaps talk to the customer and ask those questions directly.
So it is a win-win-win. The product owner gets insights that they otherwise would not get, salespeople get to influence product development to fit the customer's need, and the customer finally gets a product that isn't a burden on the way they work.
What advice would you give to someone who is just starting as a product owner?
Create the win-win-win.
Product owners should try to understand what the salespeople are already doing, how they are engaging with customers, what kind of questions they are asking. Then when sales come to you (Product Owner) with a list of features, a, b and c, chat with the salesperson. Ask them how feature 'a' helps the customer and what problem is the customer facing? And what reasons are stopping the customers from buying? And how would feature 'a' help you overcome those objections?
Start from the perspective that salespeople know things you don't know; they probably know many things you don't know. And then, your job is to figure out what those things are and how they can help you develop a product that ultimately serves the customer better.
The next step is to make the MVE. Don't go back to the development team and give them 20 features to develop. Instead, experiment and collaborate with a salesperson to run experiments. Experiments can be as simple as just paper prototypes to show to particular customers or interview questions that you ask the salesperson to ask to validate some of your assumptions and risks.
What's been a recent insight for you, Vasco?
Vasco believes his most crucial insight is a sales insight, developed over years of building his own products and trying to sell them. Eventually, Vasco figured out that his role as a product developer is not really to develop products. It is to help customers be successful. Take the 'how can I serve' perspective.
Key Takeaways
1. Focus on how we can serve
Focus on serving other teams in our business as well as external customers, establishing a culture of collaboration, continuous improvement and innovation. To do this we need to understand the goals and motivations of internal teams as well as customers and the challenges they face in achieving these. We then need to understand why internal teams and customers seek certain goals and why they have the challenges they are facing. This information allows us to develop products and services or simply improve our processes in ways that will truly help the people we serve which will help us in return.
2. Minimal viable experiment
The MVE, Minimal Viable Experiement provides a simple, fast way to test our theories on how we can improve and learn from this. The MVE concept is about developing the minimal viable approach to product development or improvement to share with a customer and gain their thoughts and feedback. We can learn from this feedback rapidly, make adjustments and improve and present again. This rapid experimental approach is at the heart of creating an innovating agile culture.
Quotes
03:28min I had been reading a lot about Lean, not in an IT context, but rather, a manufacturing context. So I was already very much, I think, primed to accept that repeatable processes are the only thing that guarantees future improvement.
06:15min I started by applying what I already knew, like the Lean principles I had. And I said, Okay, so if I want to do around 10 to 15-minute episode every day, what do I need to put together? And I started working on the system, everything, like the people that helped me ,the process that I follow, the tools that I use, everything, to get that up and running. It wasn't easy to for a while, but after a while it started running. And now it's kind of something I spend a few hours per week on, but kind of just rolls into the work that I do.
09:07min And behind this, there's an idea, which is that you can't learn if you don't have the theory. And what the Toyota kata gives us, it forces us to start to clarify to uncover to discover the theory that drives our actions. And I think that's a very important aspect of the whole work, which is also what Scrum tries to bring to product development teams.
13:40min For me, what's most important about that engagement between product owners and salespeople is when product owner start to understand the reason why salespeople bring in certain features repeatedly. They start to understand the customer's language, and very important for me, and that's what I tell all the product owners that I train and coach is to use, on purpose, customer language in the product vision.
16:05min There's only one phrase in your customer's mind. And that phrase is there all the time. And the phrase goes like this. What have you done for me lately? And they ask that question from your product every single time they interact with your product. And your product needs to shout that answer all the time. What have you done for me lately? Right? And, of course, it has to be designed with that question in mind, right? We don't add features to a product. We solve problems for a customer.
23:39min And the amazing thing happened and that was kind of a lightbulb moment for me, is that once you help salespeople and business development people to start to think a little bit like problem exploration perspective, they go to a customer and they are really good at engaging with the customer, and really good at asking questions, and really good at helping the customer reveal how your product can help them succeed. Which is amazing, right? Wouldn't we all want to have the answer to that question?
Links
Brad
Brad is proud to support many Australian businesses. You can find him on LinkedIn here. If you’d like to speak to him about how he can help your business, call him on 0402 448 445, or email bjeavons@iqi.com.au. Our website is www.bradjeavons.com
Vasco
LinkedIn and the Scrum Master Toolbox.
Written by Emily Jeavons
Comments