Agile Product Development

Join Murray Robinson and Shane Gibson in a conversation about Agile product development. discuss what a product is and what a product manager does.  We talk about the value of customer feedback and the need to test your hypotheses.  We define minimum viable products and discuss technical debt, scaling and co-designing products with customers.  And we talk about how you can move from a project to a product mentality and the value of applying an iterative approach to your marketing and sales

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Shane: Hey Murray, good to catch up again. 

This week we’re going to talk about product. 

Murray: Yeah, so, I want to talk about products, because the reason we do Agile is to create better products and services for our customers and users. That’s the measurable outcome. That’s the purpose. So that’s what I want to talk about.

Shane: Yep, I’m on board with that one. 

What’s the definition of a product? Because you said product and services, so are products and services different? 

Murray: No, not really. Product is a package of goods and services that you provide to a customer or user so that they can get some sort of outcome. And typically they pay for it in some way and that revenue is what allows you to develop the product or service.

Shane: Yep, that’s a good definition. 

There’s two areas that I’m engaging in an agile way with products right now. So one is as a co founder of a startup, we’re building a software as a service product in the data space, and then when I’m coaching data analytics teams, one of the first things we need to agree is actually what’s the definition of a data product. The idea of a software product is quite well known. The idea of a data product is still emerging. 

Murray: Yeah, so a product can have some physical things or it could be completely a service It’s usually a mix but the thing is it’s a package so that the person buying it doesn’t have to worry about the details. It’s a bit like a black box. I buy this thing to solve my problem or to give me some benefit. And I’m buying it because I believe in the people who are offering it. I believe story they’re telling and the promise they’re making. And I think that’s worth my money or my time. So I’m buying it expecting it’s going to solve some sort of problem for me, but I don’t want to worry about all the details.

Shane: And sometimes they still have to worry about some of the details, maybe it’s not a product that is completely out of the box, you have to do some stuff. Take Ikea, when you buy one of their products you’ve still got to get your little Alan key out and put it together. But, It adds value, I get value for the money I’m giving them because most of the work’s done. 

Murray: So products involve services and services involve the customer. The customer is involved in the performance of the service in some way. But something that’s not a product is custom web development because every time it’s different.

Shane: But what happens if I package that service up for a fixed price with a lot of reusable patterns and a couple website templates that you choose from and I say to you 10, 000 for that website. 

Murray: Yes. Then it’s a product. A Product is repeatable. It’s a package of products and services that contains repeatable elements, and it’s sold at a standard price for a standard time. So I can sell you a initiative roadmap service. There’ll be, a team of people come in for two weeks and they’ll do all these things to kick off your next software initiative. And I’m going to sell it to you for 60,000 dollars or whatever it is. That’s a product. 

So a product has to be financially viable for the company delivering it so you can reinvest. Otherwise it’s not worth doing. It has to be desirable to the customer, so it has to give them something they want that’s worth more to them than the amount they’re paying for it. It has to be feasible. So it has to be technically and organizationally feasible for you to deliver. So it has to be desirable, viable and feasible otherwise it’s not gonna work.

Shane: If we looked at agile training, that is a product, isn’t it? Because it’s repeatable there’s a cost, there’s a known outcome, and there’s value if people attend your course and pay you money for it. 

Murray: So standardized training is. Customized training isn’t. Once you’ve packaged up your training, then other people can help you deliver it and you can start to become more cost effective. Let’s say it takes me three months to design a repeatable and reusable training course. Once I’ve done that, I could get somebody else to come in and help me deliver it. Then it becomes more profitable or I can reduce the price. Building it in the first place takes a great deal of time and effort. But once you standardize it then you can start to get efficiencies, which allows you to be profitable.

Shane: In a previous life, the company I owned, created some training courses. We packaged them up and sold them. We wanted to scale the delivery so as part of building out that courseware, we actually spent quite a bit of time and effort building in the facilitator notes. And with the interactive parts of the course, we spent quite a bit of time documenting how those interactive pieces were meant to work, what the outcomes of that for a student was meant to look like. Because we wanted to have, five or 10 people be able to run that course whenever it was needed . If we were just doing it as a bespoke one, we wouldn’t. We’d make it up. As we were doing it because we didn’t want it to be repeatable. 

Murray: Yeah. So that’s the difference between a one off customized thing and a product. So somebody asked me to run their training course for them and I went through it and I said, I can’t figure out what you’re doing. It seems like a whole lot of things that you want to talk about, but it’s not repeatable for me. I’d have to do quite a lot of work to turn this into something I could do. So that’s not a product.

Shane: Yeah. 

So what does it mean with an Agile lens on it. Now that we know what a product is, does it change the way we behave? 

Murray: So the product is it’s features, but it’s also it’s price. It’s the marketing message. It’s the people who are going to deliver it. It’s our business processes. It’s our policies, our rules. There’s also things like packaging that you might have in stores. There’s a lot more to a product than we normally think of it in Agile. 

Typically Agile teams are software development teams, and they’re not thinking about how do I build the price, how do I build the advertising, how do I build the business processes that people are going to use after the software is delivered? How do I recruit people? What are their roles? How do I sell it through my partners? Now, potentially all of those things could go through an Agile team as a series of activities on your backlog. But they’re not software activities. And I think what happens too often is that people doing Agile are just entirely focused on constructing something. 

The product manager has to think about all that stuff. The product manager is somebody who’s been asked by the organization to coordinate this orchestra of people to build this symphony that’s the product. As a result, they tend to be away from the software people a lot of the time. And you often hear software people complain that their product owner isn’t available to them. And I think there’s a basic lack of understanding of what a product actually entails.

Shane: When we have a squad doing scrum. And if that squad is focused on developing software, the product owner is focused on the features of that software. Sitting above that, we typically see a product manager. So what you’re saying is as well as picking up support of multiple product owners, there’s a bunch of other things that are required to make that product successful, and that’s what the product manager is responsible for. So when that happens, I tend to see other squads. That aren’t software squads, but other groups of people that are doing that work. So there might be a marketing and branding team that’s out creating the website pages and the landing pages.

Murray: Yeah, it’s typical to have an agile software team and some sort of project that is organizing all the marketing, customer service and business aspects. But I recommend that we have a product team that includes all of those business people as well as the software people. So I think the concept of a agile product team is a really good one. And all we need to do is to expand it to include all of those other aspects of the product. And we do that by adding people to the team who are going to be doing that work for the product.

Shane: So, effectively take all the skills that you need to actually deliver a product to market, put them all in the same team with the same goal and let them work together to achieve it. 

Murray: Yeah, that’s right. So the customer research and planning skills, the product development skills, sales and marketing skills, and customer service, the things you need to develop product. All in one team with, dedicated people who are T shaped and who can do multiple things like we’ve been talking about. And if you need more than 10 people, then you would have multiple teams and you would break your product up into different parts and you would have, the product manager across the multiple teams. 

Shane: So I can see how, depending on the skills of the product manager and the number of teams and the amount of stuff that needs to be done and the skill level of the team, you could, have one product manager or you could end up with a product manager and a couple of product owners. There’s a bunch of ways you could, cut it . But it’s not a product owner who’s just talking to a scrum team about the features to build and the trade off decisions. The product manager is treating it as an ecosystem, an end to end of why are we building it, what are we building , how are we going to sell it, how are we going to support it, how do we make it successful. 

Murray: Yeah. So they’re doing market research. They’re doing the business case. They’re doing sales and marketing. They’re doing customer service. They’re worried about profit and loss. They’re doing organizational change and training. And because they have got such a broad mandate they can’t, spend much time with the team doing any sort of detail around user stories. So typically I would have a business analyst in the team to do that for them. 

Shane: Yeah, I agree, I think the business analyst skills is critical within a self organizing team. 

Murray: Yeah. 

So tell me, what’s your experience been developing your own product? 

Shane: It’s been initiation by fire. I’ve always had an interest in product. I’ve dabbled in product but I don’t come from a product background. 

I just finished doing my homework on Goals, context, hypothesis, and actions to create our product strategy. So take all the ramblings that are in my brain and put it down into some very short form documents that I can share with the team that hopefully tell them where we’re going and why we’re doing some of these things. Haven’t tested it with the team yet. But that’ll be in the next two weeks. 

Murray: That’s the thing I wanted to talk about next, because product development is a series of hypotheses about what is going to be desirable, viable, and feasible, and you don’t know if they’re true or not until you test them. Typically, product development is done in a very waterfall way, but we can do it in a very agile way. And that would be by recognizing that everything we’re saying is a hypothesis. So whatever we’re doing, we need to be testing our product ideas quickly and iteratively in a lightweight way. So we can get feedback because we were very often wrong about what’s desirable, viable, and feasible.

Shane: Yeah. And that’s hard that, not over baking it, not adding in those extra features into the initial build, because everybody wants them and you think they’re the magical feature that everybody’s going to love. That’s going to make your product go viral. Really constraining yourself to we have a hypothesis. Let’s build something that either proves it’s right or it’s wrong, but get it out the door as quick as possible. That is incredibly difficult in my experience. 

Murray: It’s very difficult for me as well, Shane, because I want to have something that I’m proud of. And one of the rules from the lean startup is that you should be embarrassed by what you put out in the market to start with. That’s how you know it’s light enough.

Shane: Yeah I suppose it comes back to that conversation we need to have around MVP and what it actually means. What is a minimum viable product?

Murray: There’s two different schools of thought on this. The idea from Eric Reese is that it’s the minimum viable prototype. Something that you can get out to get feedback. It goes out into the market but it could be all duct tape and string behind the scenes. In fact, they recommend building an e commerce solution to sell something but have no back end. Just have it being completely manual to start with. Because if you’re only going to deliver something two or three times and then find out people don’t really want it, then it’s not worth spending a million bucks building the whole software behind it.

Shane: Makes sense. It just doesn’t feel right. 

Murray: I know it doesn’t, it feels counterintuitive, doesn’t it? But there’s a time when you’re developing a new product where it’s very unclear whether people want it. This is the product market fit problem. So at that time, you’ve got to experiment with a lot of different hypotheses. To find what people want and what’s viable for you to deliver. And during that time, everything should be done with string and duct tape. But once you find product market fit, then you move into the next stage, which is Scaling up and at that time have to focus on making your product robust and your experimentation moves into the Sales and marketing side of things.

So you start to focus on experimenting with different ways to generate leads and advertise and so on. So you’re not doing string and sticky tape anymore for your product. Once you’ve achieved product market fit.

Shane: And, like MVP, product market fit seems to have a bunch of definitions. The definition that I’ve read that I prefer , is the market is now buying your product in a repeatable way. So you can sell it once, twice, three times yourself. Most people can, if you can’t, you’re really in trouble. But it’s when the market’s coming to you and buying your product. That’s true product market fit. So repeatable sales, through some process is what I see as product market fit. 

Murray: Yeah, I agree. Once you get some sort of product market fit, then you need to make your products stable. You should have a core product which works. Then you can start doing more string and sticky tape stuff on the advertising and the marketing cause that’s where the risk is now. 

Shane: And so you could also see a possibility that you’re going to change product managers through that cycle as your focus changes. Because to find that uniform product manager that can cover all those things is going to be hard. So you either need to scale up the number of product managers to get more specialist skills, or you need to maybe upscale your current product manager in those other areas, or swap them out as you switch from focusing on building a product and seeing if anyone wants to use it to scaling the product the channel, the sales and the support and all that . 

Murray: I wouldn’t switch because the person who has developed a product has tremendous insights into customers and what they want and what their journey is. They just need to switch their focus from building to marketing. What I would do is get them some support with marketing specialists who can help them with advertising , lead generation and branding.

When I was a product manager. I worked across the whole life cycle and I don’t think you should see them as being separate. It’s common in, large organizations to have one product manager who does research. A project manager who builds the product and then another product manager who does sales and marketing. I think that’s actually a big mistake because you need to have a unified idea of the product that goes all the way through its lifecycle, for it to be effective. 

Shane: So again, just bringing some of that agile mindset where we try to remove or restrict handoff’s between people as much as possible. Where we don’t do a big chunk of work upfront and then hand it off to somebody else to do the next bit and they hand it off to the last person to do it, and it’s not till the last person’s done we get any feedback 

Murray: Yeah. So I like to think of it as having a product development flow. You have a product team that has business, design and technical people in it, and they have a flow of work. So they’ll be building some things while doing market research on some ideas. And doing some marketing on other things and supporting the customer service people in some other areas by automating some of their processes. But one team that’s covering the whole product life cycle. And the idea would be to take the big thing, you break it up into smaller things. It goes through the life cycle and you get feedback quickly. 

And you use that to learn and to improve what you’re doing.

Shane: Yeah, I love it. like the idea that everything is a hypothesis. So when we create a feature, we may have had some feedback from our customers. We may have done some market research to see if we added that feature to our product, there’s a big market for it or none of our competitors have it. But it’s still a hypothesis, so we should get that feature out as quickly as possible in front of the people that we think will use it, and then we should make sure we capture the data to be able to measure was our hypothesis true or false. And then iterate again once we have that learning. 

Murray: Yeah. And the first version of it, might not scale at all. It might be sticky tape and string. But it looks real. And then if people like it, then the second version is robust because now a few people are using it and then you get more feedback and you improve it based on their feedback and it gets better. So you’re evolving your product based on feedback from the market. You go into it with an idea, but it’s that learning from being out there which makes all the difference.

Shane: So there’s an agile pattern that’s all around technical debt. An engineering team get taught, don’t bake technical debt into your product because you’re going to have to go back and refactor it and pay it later. But with this way of working where we say we have an hypothesis and we want to get out and prove it’s true or not early and chewing gum and string, as you said, we’re effectively baking technical debt into that. So again, we’ve got to be really clear about when technical debt’s okay and when it’s not, otherwise the team’s going to get confused. 

Murray: I think you just need to understand as a team that the first version might look okay but it’s completely manual behind the scenes. And so therefore it’s not going to scale at all. But on the other hand, the cost of building something like that to test it might be 1 percent of the cost of building something scalable and why build something robust and scalable if it turns out that people are just not going to use it, it’s too expensive.

Shane: Yeah. So again, we have to be really clear and we have to come up with a shared language so people understand where in that product life cycle each of these things are. There’s no misunderstanding that this quick and dirty chewing gum and string we did just to test the hypothesis can’t just go live when suddenly a thousand customers decide to buy that product.

Murray: it’s a good point, Shane, because often business people will say to a technical team, just get it working with chewing gum and string, and we’ll sort it out later. And then they’ll come back later and get upset that it’s not working when you’ve got three people using it at the same time. So there needs to be a common language and understanding. And this all comes back to the Agile values of openness, honesty, transparency, working closely together. The business and technical people work together every day as a team. 

So have this idea of one team. Everybody working on the product is in the same team, inside, outside, legal, software, marketing, developers, infrastructure, you’re all just in one team. You have a product team all the way through the whole life cycle to operations. And if you have to have multiple teams, then they’re part of one group, which you might call a tribe if you like that language.

Shane: Yeah. And it’s a scaling problem again, because a squad or a team can not be more than nine people. So I get your vision as we’re building a product. All the things that relate to the product should be delivered by one team. Just haven’t seen it myself. 

Murray: It can be done. 

Shane: yeah. Just to pick up on the other one so I can rant for a second. So that idea of just do it quick and dirty. Yeah, it’s okay. And then oh, what do you mean it doesn’t scale? It’s the same thing as when a team gets asked to do a proof of concept. To prove a hypothesis. The hypothesis comes out as being true, and then all of a sudden they get told to make it live as quick as possible. The proof of concept should be deleted. The code should be removed. It should be scrubbed, and we start again. Because the team have taken shortcuts, quite rightly, because they’re just proving the hypothesis. So without setting those expectations, without that business agility, without that transparency without that honesty, then bad things happen. 

Murray: Yeah, that’s right. The other big change Shane is that the way you measure success is really different when you take a product lens on what you’re doing. So success should be measured by your objectives and your key results that you’re looking for. And they would be things like revenue, uptake, new customers, retention, profitability, referalls, , feature usage. Things like that. 

Typically in Agile teams or Scrum teams, we talk about velocity. if you put a product lens on it, velocity and a point aren’t important. What’s really important is measurable feedback from users and customers. 

It’s much better to have a product team that has a goal for increasing usage by 20 percent or increasing leads by 20 percent and have them focus on that, then it is to have a product team that has a whole long list of features that they’re pumping out.

Shane: And also, it’s really important that we look at the way that team’s funded. So they’re not a project. They are a team building a product. Products never stop unless you’re going to can the product. So there should be a bunch of funding that pays for those team members to keep iterating on the product, and then you’re setting them goals of what outcomes you’d like to achieve, what levers you want them to move. We want to make more money, or we want to onboard the users for that product quicker or faster or with less effort. We’re looking for some outcomes. And the money’s there for the team to iterate, to achieve that outcome. They’re not given project budgets for a set of features because that’s a project mentality, not a product mentality. 

Murray: Yeah, exactly. So a product mentality fits very well with the idea of a long running product team. That’s focused on outcomes, which is where I see everybody moving to now in Agile thinking anyway. 

Shane: Yeah, I also see the word product being used a lot as a veneer over a lot of project and other ways of working. 

Murray: I agree that does happen because organizations are just doing this with everything. They’re putting lipstick on a pig with their traditional ways of working and calling it Agile . An organization that’s fallen way behind, may need to make a big effort to do something for a while to catch up, in which case a project is probably quite good. But it would have been better for them to just have invested in their product the whole time to keep it up to, what the market wanted. 

And if you have a long running product team that is focused on business outcomes then everybody in the team can contribute to helping achieve that outcome. Then a developer can say, Hey, I use this other website and they have this really cool way of generating leads that got me in. Why don’t we do that? And then that developer can bring their whole selves and all of their experience to contribute towards the product instead of just a feature.

Shane: Yeah, we’re giving them an outcome or a problem to solve and they’re using their skills to figure out how they’d solve it within the product they’ve got.

Murray: You have to be really smart to be a developer and really good at solving problems. Now, most developers are probably going to come up with a coding solution to a business problem, but let’s not underestimate the value that those people in the team can add to the product. They might say for this hypothesis I think there’s a really easy way for us to test if people are interested in it. We can just put some tracking code in here and do some A B testing. I reckon I could do it in a couple of days and then we can test two different offers.

Shane: So same things we do with scrum teams, tell them where we want to go. And then, the what, the why, but not the how. 

Murray: Yeah. So I have to say I’ve found this quite difficult to get people to do. I’ve suggested a few times that we do this outcome focused thing because the business people tend to be very project focused. And I think that’s because that’s the way that their work is funded internally by their organizations.

Shane: I think also as humans, we invariably would like to focus on the solution. We love to solutionize. We feel more comfortable creating the solution than defining the outcome. So it is a, complete change in terms of the way you work. If you’ve got an end to end product team and you’re saying to them, this is the lever we want moved, go forth and be successful. But feel free , to use Chewing Gum and String right at the beginning and I won’t tell you to make it live next week when it’s successful.

Murray: would these ideas apply to your product startup , Shane? 

Shane: We’ve got some interesting challenges being remote only. And also the majority of our team are part time and they’re not domain experts. So there’s some challenges in there and getting our way of working to be collaborative and self organizing, and we’re still going through that journey at the moment.

Gotta say, I’ve got some more thoughts around it right now in terms of the way I’m going to change my behavior as the Chief Product Officer. To try the idea of bringing up some of the hypotheses and see how other people within the team would solve them. Rather than me thinking it all the way through And being more directive, which is probably what I’m doing right now. 

Murray: yeah. As a traditional project manager, I thought I was completely responsible. So I had to make sure it happened. . And then Agile was all about shared responsibility. It’s the same in the product area. It’s very easy to think you’re totally responsible. You have to come up with all the ideas. You have to come up with a perfect product and put it out and then people love it and buy it and you’ll be rich. But it’s actually quite revolutionary to realize that you don’t have all the ideas. And that you can’t possibly, no matter how smart you are. And that actually you need to share responsibility for your product with your consumers, your buyers, and with your team, because they’ll tell you a lot about what will work and what won’t work. 

There’s a whole philosophy around this called co design, which came out of Sweden. Co design is the idea that you design something jointly with your customers.

Shane: Yeah it doesn’t mean that you go ask them for a bunch of requirements and go away and build it. You treat them as part of your team and they’re providing that time commitment and you’re building it together.

Murray: Now, if you’re in a business to business situation, then you may find that there are people in your clients who are happy to spend that time with you, but if you’re in more of a consumer situation, then the way you get that time from people is you pay them. To join your focus groups and customer counsels and things like that. 

There are always people who will want to get really involved and have a lot to say. It doesn’t mean you have to do what they say, because there’ll be things that people are rabid about which are you can’t do economically, or that’s just not viable, or as you feel it’s not going to meet your vision.

You don’t just give over responsibility to other people. You’ve still got to have the vision and the drive and you’ve got to inspire people and bring people together, but you just don’t have to do everything yourself.

Shane: If you’re using the concept of hypothesis, your customers are co designing those hypothesis with you. They’re saying it’d be really good if we had these features, because we’d use them this way. Test it. What’s the minimum viable you can get out the door, to prove that other customers like them will do it that way, and the value will be there. So it’s just a theory. You have to then create some actions, and then go and prove the theory was True or false, and then, scale accordingly. 

Murray: My mistake in the past has been to put too much effort into designing the perfect thing. Now, I would be much more focused on hypotheses and getting feedback and talking to people. Get out of the building and talk to people, that’s what Steve Blank says.

Shane: Yeah, and one of the things that we do consistently is using, interactive wireframes as a way of testing something before we start development on it. So come up with a bunch of options, get some people to help us go through it and see if it’s doing what we think it should before we go to the cost and expense and time of starting to build it into the product. 

Murray: How would you summarize what we’ve been talking about? 

Shane: So I think that we’re going to see the term product become more and more prevalent. We haven’t seen the big three issue their white papers about transforming to be a product company yet. So I think it’s going to become more prevalent.

I agree with you that it’s more than just building a piece of software. That is that end to end process and all those things that you have to do to make a product successful and therefore that role of product manager or chief product officer or whatever title you want to give them who are responsible for achieving the outcome that product’s meant to give the organization and their customers is really, really important. 

We tend to have a scaling problem like always. We end up with teams that are bigger than 10, and our default behavior is to create teams of specialists that hand off to each other and we have to break that cycle, and figure out ways of scaling where we have self organizing teams that can do all the work themselves without relying on somebody else. 

Murray: Yeah I’m seeing the same sort of thing. I, think that the consulting companies are about to start writing papers on how they’ve transformed a bank into a product organization. Also the Scrum community is trying to change the product owner role into a product manager role. There’s a lot of Scrum people who are saying, no, product owner is a product manager. And they should be empowered to set the pricing and do the marketing and everything, which is radically different to what it’s been in the past, because the product owner has always expected to spend, nearly all their time with the scrum team. So how are they going to do all that other stuff? It’s not possible for the product owner for a team of say 10 people to give you all the detailed user stories and also do everything else we’ve talked about at the same time. The team has to take on a lot of that responsibility and be one team and have all the business people in it. 

The other thing I just wanted to note is that this is a great way of doing your sales and marketing. Let’s say you’ve gone through the journey of developing your product to the point where it’s working in the market. And you’re now trying to scale up and get more people on. This whole idea of one team with business and technical people testing hypotheses is a great way to approach your marketing as well. Because it’s very common for people to do waterfall marketing. They spend millions on creating ads and big media buys. But instead of that, we could be treating, all these things as hypotheses as well. 

We’ve got 10 or 20 different communication messages. Let’s just try them out. And test them and measure them and see what works and what doesn’t. Let’s try our different media buys out on different things. Advertising on site A versus site B. Digital marketing people have been doing this for quite a long time now. So I would just bring that into the product team. So there’s less technical people and more marketing people in there. 

I think this is the future. I can really see there being a lot of value in applying these Agile ideas to product development. And it’s very helpful for what we’re doing to get outside this feature factory that so many people are in.

Shane: Excellent. All right. So call it quits with this one.

Murray: Yeah, I think that’s been an interesting discussion, what do you think Shane?

Shane: I think they’re always interesting discussions. I never know where we’re going to end up. It was a good one as always. 

Murray: All right, thanks Shane.

Shane: right. Catch you later.

Murray: That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d help to create high value digital products and services, contact murray at evolve. co. That’s evolve with a zero. Thanks for listening.