Agile product development
Join Murray Robinson and Shane Gibson in a conversation about Agile product development. What is a product? What do product managers do? The difference between product managers and product owners. Moving from functional silos to cross-functional product teams. Integrating design, marketing and technology. Scaling product management across multiple agile teams. Requirements as untested hypotheses. What is an MVP? Finding product-market fit. Waterfall vs agile product development. Technical debt and prototype testing. Product vs project funding, outcome vs solution focus. Codesign and agile marketing.
Shane Gibson
Welcome to the no-nonsense Agile Podcast. I'm Shane Gibson.
Murray Robinson
And I'm Murray Robinson.
Shane Gibson
Hey, Murray, good to catch up again. This week, we're going to talk about products.
Murray Robinson
I want to talk about products because increasingly, people are recognising that 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. Yes, Agile can help you be faster and more efficient. It can mean that your people are happier and you can respond more quickly to changes in the environment but for me, the real outcome is better products and services. That's what I want to talk about.
Shane Gibson
I'm on board with that one. What's the definition of a product? Are products and services different?
Murray Robinson
A product is a package of goods and services that you provide to a customer or user so that they can achieve a goal. They typically pay for it in some way and that revenue allows you to develop it.
Shane Gibson
That's a good definition. I look at products from two different points of view. One is as a co-founder of a startup that is building a software as a service product in the data space. The second is when I'm coaching data and analytics teams. One of the first things we need to agree on is the definition of a data product. It's hard to get that definition. The idea of a software product is well known but the idea of a data product is still emerging, and therefore, there are lots of opinions about what it is and what it isn't.
Murray Robinson
A product can have some physical features, or it might not. It could be completely a service. It's usually a mix. But the thing is, it's a package. The person buying it doesn't have to worry about the details. It's almost like a black box that I buy to solve my problem or to give me some benefit. I'm buying it because I believe the story they're telling and the promise they're making. I'm buying it expecting it's going to solve some problem. I don't want to worry about all the details.
Shane Gibson
Sometimes you 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. When you buy an IKEA product, you've still got to get your key out and put it together. But that adds value. I get value for the money I'm giving them because most of the work is done. I've only got the last 10% or 20% depending on how I put it together.
Murray Robinson
Products that involve services involve the customer in the performance of the service in some way. On the other hand, custom web development is not a product because it's different every time.
Shane Gibson
What happens if I package my web development service. So for $10,000, I will build you a website with standard features from a few templates that you choose from. Is that a product?
Murray Robinson
Yes, then it's a product. That's how you turn a service into a product. A product is repeatable. It's a package. It doesn't have to be totally manufactured. There can be manual elements and variability. It's a package of products and services that has a lot of repeatable elements that is sold at a standard price in a standard way. If I sell an initiative roadmap service that a team of people will do in a standard way with standard deliverables in a standard time for $60,000 then that's a product. I've productized my planning service by standardizing the service I'm offering.
Shane Gibson
Sometimes I help organisations do data blueprints. I package it up as a product that gets them a tick in the box in one of their governance steps so they can carry on and do the work. I've packaged these blueprints up so they have defined inputs, steps and artefacts for a standard amount of money. I used to say, the time and cost would depend on what you wanted but now I effectively have a product. I might put the price up though because it's not $60,000. Maybe I'm under-selling them.
Murray Robinson
I'm talking about a planning service that has multiple people involved. A product has to be financially viable for the company to deliver it. It has to pay for itself and make a profit otherwise it’s not worth doing. It also has to be desirable to the customer. It has to give them something they want that's worth more to them than the amount that they're paying for it. And it has to be technically and organizationally feasible for you to deliver. A product has to be desirable, viable and feasible otherwise, it's not going to work.
Shane Gibson
Agile training is a product, isn't it because it's repeatable? There's a cost, there's a known outcome and there's value for the people attending your course and paying for it.
Murray Robinson
Standardised training is a product but customised and non-standardised training isn't. If you package up your training so that other people can deliver it then it's a product. Let's say it takes me three months to design a repeatable and reusable training course that somebody else could deliver. When it's standardised I can drive down the costs and make it more profitable or reduce the price. Building a repeatable and reusable course takes a great deal of time and effort but once you standardise it then you can start to get efficiencies which allows you to be more effective and profitable.
Shane Gibson
There's another dimension to determining a product. In a previous company, we created and sold some training courses. We spent quite a lot of time and effort building the facilitator notes, documenting the interactive pieces and defining the student outcomes so that we could have many different people run the course whenever it was needed. If we were doing a bespoke course we would make it up as we were doing it because we didn't want it to be repeatable.
Murray Robinson
That's the difference between a bespoke service and a product. Somebody asked me if I could run their training course for them. When I went through their course I found that it was just a lot of slides on things they wanted to talk about. I'd have to do quite a lot of work to turn this into something I could deliver. So that course wasn't a product.
Shane Gibson
Does it mean we have to do something when we're building a product? What does it mean with an Agile lens on it? When we know what a product is, does it change the way we behave?
Murray Robinson
Building the product is not the product itself. The product is the outcome. There's a lot more to a product than building software features. A product is its features plus the price and the marketing message. It's the call centre people who are going to talk about it, and the customer service people who are going to support it. The product includes the product business processes, policies and rules which are defined in a product information document. It includes the packaging and presentation you have in stores. A doctor's product includes the doctor's office and chairs. There's a lot more to a product than we think of in software development. Agile software development teams are not thinking about how to design and build the product price, the advertising or business processes. They aren't thinking about roles and recruitment or how to sell through partners. All of these things could be done by an Agile product team but they're not software activities so they are missed. Too often people doing Agile are entirely focused on constructing software and they don't think about any of the other stuff the product manager has to think about. The product manager has to coordinate an orchestra of people to build a product and as a result, they tend to be away from the software people a lot of the time. You often hear software people complain that their product owner isn't available to them. That reflects a basic lack of understanding of what a product is from Agile people.
Shane Gibson
So, we talked last time about Spotify. I'm going to use the word squad from now on because it's a term that I can reference. So, when we have a squad doing Scrum with a product owner then that squad is typically focused on developing software and the product owner is focused on the features of that software. Sitting above that we might see a product manager. But that role is, in my view, often not well defined. What you're saying is that there is a lot more to successful product management than supporting squads and product owners. I tend to see other groups of people doing that work outside of squads. There might be a marketing and branding team, that's creating the website pages completely in isolation of the software squad. Is that what you see?
Murray Robinson
That's the usual way it's done but it's not the way it should be done. It's typical to have a product development project that has an Agile software team, a traditional marketing team and other people separately organising customer service and business processes. I think we should have one product team that includes all of the business people and the software people. Maybe 50% software related people, and 50% of those other people. The concept of an Agile product team is a good one. All we need to do is to expand it to include all of those other aspects of the product. We do that by adding people to the team who are going to be doing that work for the product.
Shane Gibson
We're going to have a scaling problem but we'll talk about that later. So we should take all the skills that you need to deliver a product to market, put them all on the same team with the same goal and let them work together to achieve it. That's an Agile way of working.
Murray Robinson
To develop a product you need customer research and planning skills, product development skills, sales and marketing skills, and customer service skills. The solution is to put all of these skills in one team with dedicated T shaped people who can do multiple things. If you need more than 10 people to develop a product, then you would have multiple teams that deal with different parts of the product with one product manager across all the teams. Scrum says that if you have multiple teams working on one product then you only have one product owner. You don't have a product owner in each team. If you've got 10 Scrum teams, you have one product owner who sits across all 10. The product owner at that level doesn't write stories. They delegate the details to each team and each team helps them. I don't think many people understand that you don't have to have a product owner per team when you have multiple teams. But in any case, a product owner and product manager overlap but they are not the same. A product owner is focused on serving the Scrum team where a product manager has a bigger focus. A product manager could be the product owner but they will be doing a lot of other things as well.
Shane Gibson
When there's too much work to be done and that work has to be done, then you have to scale the number of people. And you have to organise the work so that one person doesn't become the bottleneck. I can see that you could have one product manager supported by a couple of product owners. There's a bunch of ways you could cut it and create the matrix. But picking up on your point, a Product Manager is not a product owner who's talking to a Scrum team. A Product Manager is treating the product as an end to end ecosystem. They are asking - why are we building this? 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 Robinson
A Product Manager is responsible for market research, the business case, product design, software development, sales and marketing, customer service, organisational change and training. They're worried about profit and loss. They don't have time to define detailed user stories for an agile team. The team has to do that for them. Typically, I would have a business analyst in the team, I want to bring back the business analyst role. Because they're awesome.
Shane Gibson
I agree. Business analyst skills are critical within a self-organising team.
Murray Robinson
We also need to consider the product development process the team goes through. Typically, we have an idea, do some research, build a business case, define the product, build software, create a marketing campaign and launch it. It's a waterfall process that takes years. I've been a product manager twice. Once for a large insurance company where I developed and marketed a successful consumer product and once as a product director for a digital agency where I turned their customised services into standardised products. So I've got some good experience outside of Agile with this stuff. What's your experience of developing your own product? Do you see where I'm coming from?
Shane Gibson
It's been an initiation by fire. I've always had an interest in products, but I don't come from a product background. My co-founder is the technical one. I had an interest in learning more about products so I became the chief product officer. I've been learning as much as I can about product management while we have been building. We're up to five people now; they're all remote. So how do we cover all those things so that the team understands where we're going. I decided that I would drink my own champagne and engage a product coach. He educates me on the things I need to know as a product manager and I go and do my homework. Funnily enough, I had a session yesterday where I finished doing my homework on goals, context, hypothesis and actions to create our product strategy. I took 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 will explain where we are going. I haven't tested it with the team yet, but that'll be in the next two weeks.
Murray Robinson
Product development is a series of hypotheses about what is going to be desirable, viable and feasible. 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 work in an Agile way by recognising that everything we're saying is a hypothesis. Whatever we're doing, we need to be testing our product ideas quickly and iteratively in a lightweight way. We need feedback because we are often wrong about what's desirable, viable and feasible.
Shane Gibson
It's hard not to add all of those extra features into the initial build that you think everybody wants. Magical features that everybody's going to love; that's going to make your product go viral. It's incredibly difficult to constrain yourself to test a hypothesis before you build it.
Murray Robinson
It's also difficult for me. I don't want to put out something simple and crappy for people to look at. I want to have something good that I'm proud of. One of the rules from the Lean Startup, which is about Agile product development, 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 Gibson
Again, it's still got to work. What is the minimum viable product? What does viable mean?
Murray Robinson
Steve Blank and Eric Ries say that an MVP is the minimum viable prototype that you can get out to get feedback. It could be all duct tape and string behind the scenes. They recommend that you test whether you can sell something by building a very basic front end with a completely manual back end. It's not worth spending a million bucks building a robust software solution only to find out that people don't want it.
Shane Gibson
That makes sense but it doesn't feel right.
Murray Robinson
I know it doesn't. It feels counterintuitive, doesn't it? We don't want to be embarrassed. When you're developing a new product there is a point where it's very unclear whether people want it or not. This is the product-market fit problem. You've got to experiment with a lot of different hypotheses to find what people want and what is viable for you to deliver. During that time everything should be done with string and duct tape. Once you find product-market fit then you scale up and make a robust product. Then your experimentation moves into the sales and marketing side of things. Once you have product-market fit you can focus on experimenting with different ways to advertise and generate leads. You're not doing string and sticky tape anymore for your product once you've achieved product-market fit.
Shane Gibson
Like MVP, Product Market Fit seems to have a bunch of definitions. The definition that I prefer is that the market is now buying your product in a repeatable way. You have fit when people are buying a standard product in a standard way without you doing every deal as a one-off with a whole lot of effort. People are coming to you and buying your product through a repeatable sales process.
Murray Robinson
I agree. Once you get some product-market fit, then you need to make your product stable, repeatable and reliable. Then you need to experiment with advertising and marketing and do the string and sticky tape stuff there because that's where the risk is now.
Shane Gibson
I can see that you could change product managers as your focus changes from product development to marketing. It's going to be hard to find a product manager that can cover all those things. You either need to scale up the number of product managers to get more specialist skills, or you need to maybe upskill, your current product manager in those other areas, or swap them out. that as you switch, you've flipped the switch from focusing on building a product and seeing if anyone wants to use it, to then scaling the product and scaling the channel and the sales for that product and the support and all that good stuff.
Murray Robinson
I wouldn't change the product manager. The person who developed a product has tremendous insights into customers and what they want and what their journey is. They can switch their focus from building to marketing with the support of marketing specialists who can help them with advertising and lead generation. That's what I did when I was a product manager. I worked across the whole lifecycle. I think you should do them separately. It's common in large organisations to have one product manager who does research, another product manager who builds the product (often called a project manager), and a product sales and marketing manager. Sometimes the person who does the market research also does the sales and marketing. It's a big mistake to split them into those three roles. To be effective you need to have a systematic, unified idea of the product that goes all the way through its lifecycle. That's what Steve Jobs and people like that did.
Shane Gibson
If we have an Agile mindset we would try to remove or restrict handoffs between people as much as possible. 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 so that it's not until the last person's done that we get any feedback. We don't want to adopt that waterfall process when we have better ways of working.
Murray Robinson
I like to think of it as having a product development flow. You have a product team with business, technical and design people who have a flow of work. They have ideas or hypotheses about the product. They research them, plan them, define them, build them, review them, deliver them and support them. But it's the same team and they're not doing it in a waterfall way. They're doing it continuously. They'll take a big hypothesis and break it down into small things. They’ll do market research, product development, marketing and customer service automation for different parts of the product at the same time. One team that's covering the whole product lifecycle can take your ideas and push them through the cycle quickly. In an agile product team, we take a big idea, break it up into smaller things, go through the life cycle, and get feedback quickly, so that we can learn and improve what you're doing.
Shane Gibson
I love it. I specifically like the idea that everything is a hypothesis. When we create a feature, we often do some research to see if there's a market for it but it's still a theory. We should get that feature in front of people as quickly as possible and capture the data to measure if our hypothesis is true or false, then iterate again once we have that learning.
Murray Robinson
And the first version of a product feature might not scale at all. It could be sticky tape and string but it looks real. If people like it then you make the second version more robust. When a few people use it, then you can improve it based on their feedback. So you're evolving your product, based on feedback from the market, like a species evolves in the jungles in Africa. It's that learning which makes all the difference.
Shane Gibson
In engineering teams are taught that you 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 have a hypothesis, and we want to get out and prove that's true or not early with chewing gum and string then we're effectively baking technical debt into the product. We've got to be clear about when technical debts are okay, and when it's not otherwise the team is going to get confused.
Murray Robinson
We are developing versions of our product features. You need to understand as a team that the first version might look pretty, but it's completely manual behind the scenes so it's not going to scale at all, it is going to have technical debt. But the cost of building something simple to test might be 1%, of the cost of building something scalable. Why build something that's completely robust and scalable if it turns out that people are not going to use it? It's too expensive.
Shane Gibson
We have to be clear and have a shared language so that people understand where we are in that product lifecycle. There are lots of techniques we can use. There's the idea of feature flags, where we can turn on features for a subset of our customers to test them. There's a bunch of ways we can be clear where that feature is so that everybody's on the same page. So there's no misunderstanding that this quick and dirty chewing gum and string solution we did to test the hypothesis can go live when 1000 customers decide to buy that product.
Murray Robinson
It's a good point, Shane, because often business people will say to a technical team, get a feature working with chewing gum and string and we'll sort it out later. 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. There needs to be a common language and understanding. This all comes back as well to the Agile values of openness, honesty, transparency and the business and technical people working together every day as a team. I have this idea of one team, where everybody working on the product is in the same team, whether you're from a supplier or from an internal department, whether you're from, legal, software, marketing, or infrastructure. You are all in one team, like DevOps, where you have the developers and the ops people in the same team. I've heard this called ProdOps. The idea is that you have one team, from the product all the way through the whole lifecycle to operations. If you need multiple teams, then they're part of one group, which you might call a tribe, if you like that language.
Shane Gibson
I haven't seen a full end to end product team. We still struggle with an organisation that's going through a digital transformation from a static website to a smartphone app. They need data to drive that app yet, the digital team is completely separate from the data team, and they do horrible handoffs, and everybody's unhappy. Those two sets of skills should be slammed together into one self-organising team. I get your vision that we're building a product, and all the things that relate to the product should be delivered by one team. I haven't seen it myself.
Murray Robinson
It can be done.
Shane Gibson
To pick up on your other point that business people ask you to do a quick and dirty solution and then get upset when it doesn't scale. It's the same thing when a team gets asked to do a proof concept to prove a hypothesis. If the hypothesis comes out as true then the team are told to make it live as quickly as possible. The proof of concept code should be removed because the team have taken shortcuts to prove the hypothesis. Without setting those expectations, without that business agility, without that transparency and honesty, then bad things happen.
Murray Robinson
The other big change is that you measure success differently when you put a product lens on what you're doing. Product success should be measured by the key results that you're looking for. They would be things like revenue, uptake, new customers, retention, profitability, referrals and usage. Whereas, typically, in Agile or Scrum teams, we talk a lot about velocity and story points. If you put a product lens on it, velocity and points aren't important. Business value points can help you get there but what's important is measurable feedback from users and customers. It's much better to have an Agile product team focused on increasing usage by 20% or increasing leads by 20% than it is to have them focus on delivering a long list of features.
Shane Gibson
And also it's important that we look at the way that teams are funded. Product teams aren't a project, they are a team building a product. Product teams never stop unless you're going to cancel the product. There should be a bunch of funding that pays for those team members to keep iterating on the product. Then you set the goals for the outcomes you'd like to achieve. So, we want to make more money, or onboard users faster and with less effort. The money's there for the team to iterate to achieve the outcome. They're not given project budgets for a set of features, because that's a project mentality, not a product mentality.
Murray Robinson
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.
Shane Gibson
I also see products being used a lot as a veneer over projects and other ways of working.
Murray Robinson
Organisations are doing this with everything. They're painting over their traditional ways of working and calling it Agile so they will do it with products as well. But I think there is still a place for projects. An organisation that's fallen way behind may need to make a big effort to catch up, in which case, a project is quite good. But it would have been better for them to have invested in their product the whole time to keep up with what the market wanted. Also, if you have a long-running product team that is focused on business outcomes, then everybody in the team can contribute to that outcome. If the whole team is focused on generating leads then a developer can suggest that you use a cool way of generating leads that got them in. We should encourage our developers to use their whole brains and bring their whole selves and all of their experiences to contribute towards the product.
Shane Gibson
We're giving them an outcome or a problem to solve and they're using their awesome skills to figure out how they'd solve it in the product we've got.
Murray Robinson
You have to be smart to be a developer and good at solving problems. Your ability to solve problems is a lot bigger than coding. It's true that most developers are 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 be able to suggest an easier way to test if people are interested in a new feature through tracking codes and A/B testing plug-ins that could save days or weeks of work. When we work in silos we are not engaging the people doing the work to see if they can help do it better.
Shane Gibson
It's the same thing we do with Scrum teams. Tell them where you want to go and tell them the why, but not the how. Same thing with products.
Murray Robinson
I have to say I found this quite difficult to get people to do. When I've worked with digital marketing directors I've suggested that we take an outcome focus but I've found it hard to get them to think like that. Even though they're business people, they tend to be very feature and project focused because that's the way that their work is funded internally by their organisations.
Shane Gibson
Humans like to focus on the solution. We love to solutionize. That's a trait that most of us have. We feel more comfortable creating the solution than defining the outcome. Or we create the solution in our head, and then we reverse engineer it into the outcome that fits the solution. 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 to be moved, go forth and be successful. But feel free to use gum and string at the beginning, and I won't tell you to make it live next week when it's successful.
Murray Robinson
How would these ideas apply to your product startup that you're doing Shane? Would you do something different?
Shane Gibson
We've got some interesting challenges being remote and part-time. There are some challenges in becoming collaborative and self-organising. We're still going through that journey at the moment. Although I've got to say, I've got some more thoughts of how I can change my behaviour as the Chief Product Officer for our startup. I'd like 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 direct, which is what I'm doing now. Again, it's always easy to be an Agile coach and not drink your own champagne.
Murray Robinson
This reminds me of my transition from being a traditional project manager to being an Agile leader. As a traditional project manager, I thought that I was responsible for the outcomes and had to make all the decisions whereas Agile is all about shared responsibility. It's the same in the product area. As a product visionary, it's 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. That's the mindset we all have. It's quite revolutionary to realise that you don't have all the ideas and that you can't possibly do it no matter how smart you are. You need to share responsibility for your product with your consumers, with your buyers, and with your team, because they will add a lot and tell you what will and won't work. We should think about sharing the responsibility for the product with the customers. You need to have a vision and understand what's commercially viable and your technical people can tell you what's technically feasible but your customers can tell you what's desirable. 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 and users.
Shane Gibson
For me, 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 designing and building it together.
Murray Robinson
If you're in a business to business situation, then you may find clients who are happy to spend time with you but if you're in a consumer situation then you can pay people to provide input. You pay them to join your focus groups and customer councils. You'll find that a lot of customers and users can't be bothered but there'll be people who are very thoughtful. Those are the ones you want to develop a relationship with and get onto customer councils. There are always fans who want to get involved and have a lot to say; like a fan base for a movie. It doesn't mean that you have to do what they say. There'll be things that people want that are not economically viable, or that don’t fit with your vision. It's a negotiation between the different groups. You don't give over responsibility to other people. You've still got to have the vision and the drive. You've got to inspire people and bring people together but you don't have to do everything yourself.
Shane Gibson
And also, if you're using the concept of hypothesis, your customers are co-designing those hypotheses with you. They're saying, it would be good if we had these features because we'd use them this way. But you should test it with a minimum viable product. Get out the door and prove that other customers like them see the value. It's a theory. You have to go and prove the theory is true or false and then scale accordingly.
Murray Robinson
If I look back on my experience with developing products, my mistake in the past has been to put too much effort into designing the perfect thing before getting it out there. Now I would be much more focused on testing my hypotheses by doing something small to get feedback and talk to people. Steve Blank says we have to get out of the building and talk to people.
Shane Gibson
These days we use interactive wireframes as a way of testing something before we start development on it. I get people to go through it and see if it's doing what we think it should before we go to the cost and expense to build it into the product.
Murray Robinson
What do you think? How would you summarise what we've been talking about?
Shane Gibson
We're going to see the word “product” become more and more prevalent. We haven't seen the big three consulting firms issue white papers about transforming to a product company yet but I think it's going to happen. I agree with you that it's more than building a piece of software. There are a lot of things that you have to do to make a product successful. Therefore the role of a Product Manager who is responsible for achieving the product outcome for their customers is important. But we have a scaling problem like always. When we end up with teams that are bigger than 10 our default behaviour is to create teams of specialists that hand off to each other. We have to break that cycle and figure out ways of scaling, where we have self-organising teams that could do all the work themselves without relying on somebody else.
Murray Robinson
I'm seeing the same thing. I think that the big consulting companies are about to start writing papers on how they've transformed a bank into a product organisation. They usually pick up on what people like us say a few years later. Also, the Scrum community is now trying to change the product owner role into a product manager role. I see a lot of Scrum people saying now that a product owner is a product manager. This is radically different to what it's been in the past because the product owner has always been expected to spend nearly all their time with the Scrum team. So how they can do all that other stuff. There's been a lot of confusion in the Scrum community about this. It's not possible for the product owner for a team of 10 people to give you all the detailed user stories, and 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 with all the business people in it. The other thing I want to note before we go is that this is a great way of doing your product 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 now you're trying to scale up and get more people on it. If you have one product team with business and technical people testing hypotheses then you can apply that approach to your marketing as well. It's very common for people to do waterfall marketing. They spend millions on creating ads and getting them out with big media buys. But we could be treating our marketing as hypotheses as well. Let’s say we've got 10 or 20 communication ideas. Let's try them out, test them, measure them and see what works and what doesn't. Let's try out different media buys on different platforms and see what works. Some digital marketers have been doing this for a long time. I would bring that into the product team. Over time, the product team members might change so there's fewer technical people and more digital marketing people but it's still one product team. This idea has a lot of legs. This is the future. There have been parts of this that people have been doing for a long time off and on but I can see there is a lot of value in applying these Agile ideas to product development. It's very helpful for what we're doing to get outside this feature factory that many people are in.
Shane Gibson
We're seeing this idea in the data space. The concept of a data product has become incredibly hot in the data world at the moment. It's not well defined. I would define it as a set of data that is given to a group of people so they can make some decisions that create some actions. It's a way of chunking all the data down into smaller groups and treating them as a product to get them through the pipeline. But that idea hasn't expanded out into a full product. How do we make sure that the people using that data are supported and literate to use it? How do we measure the value of those data products? We're still at step two of productization of data, not all the way through to what is needed to build a true product like you described all the way through this podcast.
Murray Robinson
Are these data products for other people within the same organisation or for external customers?
Shane Gibson
It can be for either. There is a lot of focus in the market on data products that you sell to organisations as Dun and Bradstreet do. But data could be an internal product or an external product. It doesn't matter. It's the things we're doing to package that up and make it valuable that's important. Based on this I'm going to expand my definition of what a data product is, and what's involved in creating them.
Murray Robinson
A lot of organisations are big enough to have a team that's producing a product for other parts of the organisation, maybe it's a call centre system or some infrastructure platform. Everybody would be much better off if they treated those platforms as a real product, not some shared service that you have to use, whether you like it or not, which is generally the case.
Shane Gibson
Those shared services typically suck, because it's a bespoke service that people develop when executives yell at them. They don't treat it as a product somebody wants to buy.
Murray Robinson
Typically some executives have decided that Team A is going to build something for Team B, and neither team A or B want to do it or like the result. So, all of this product thinking can be applied to internal products as well.
Shane Gibson
Excellent. Alright, should we call it quits with this one?
Murray Robinson
That's been an interesting discussion. What do you think, Shane?
Shane Gibson
They're always interesting discussions. I never know when we're starting, where we are going to end up. It was a good one as always.
Murray Robinson
That was the no-nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with Agile contact murray@evolve.co That ev0lve with a zero. Thanks for listening.