In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by his collaborator, Sam Falco. Today they will be comparing a product-focused approach versus a project-focused approach and highlighting some of the major differences. They also cover how to apply a product mindset to a project-focused organization, and offer some key tips on how to effectively implement either.
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to the Agile Coaches’ Corner, I am Dan Neumann and excited today to be joined by Sam Falco and we’re going to be discussing the difference between taking a project focused approach versus a product focused approach. Thanks for joining Sam.
Sam Falco: [00:31] Thanks for having me again, Dan.
Dan Neumann: [00:32] So project versus product. I know in my waterfall world it was always project based. We would work with our clients, we’d get a request for a proposal, we’d respond to that. They funded it as a project with a defined start and a defined end. And by golly, we were expected to meet all the requirements in the time frame and with the quality they expected.
Sam Falco: [00:55] Yeah, exactly. The project’s, uh, approach is success is defined sway up at the beginning by doing the thing within scope, within a budget, within the estimated time and that has some problems. It leads to, um, basically your business people and your developers development team don’t necessarily talk to each other. The business team says, here’s a project, do this thing. And then we, we managed towards a bunch of tasks, um, rather than having some sort of vision for a product that we then iterate towards and validate the assumptions we’re making along the way. That’s the biggest thing I see is that in a project focused world, we delay feedback. We make assumptions that we don’t really validate those assumptions.
Dan Neumann: [01:52] Yeah. The assumptions. And boy, I remember somebody will, you know, for those who are inclined and haven’t heard it, they can Google what you get when you make assumptions, but not for this safe, uh, safe for work podcast. But you know, the, the goal was to do what had been requested, what had been defined and, and just to deliver that. Yeah. There was feedback when the quality specialists started to poke at the software and then when the customers started to do UAT. But those, those feedback loops are so far out.
Sam Falco: [02:29] Right. And the assumption is that the people who are asking for something know what they want. And of course we know that that’s rarely true. People know something maybe adjacent to what they want, but maybe not even that they just have a vague notion and we build what they said they wanted and we built something that maybe isn’t actually as useful as what we could have come up with if we worked in a different manner.
Dan Neumann: [02:56] And I think projects can work for small and easily defined. The episode prior to this one was Christy Erbeck and I, and we actually talked about the scenarios under which waterfall is better than an agile approach for part of that podcast. And there are places, I think maybe where a project is a better approach. I just had a fence installed in the backyard. I don’t need them to go back. Well actually I do need them to iterate on the fence now that I mention it cause they wanged part of it, but they, uh, they got one of the, uh, one of the parts isn’t level so they’re gonna have to come back and fix it. But in general, I hope they will fix that. And then I will not have fence workers in my backyard again.
Sam Falco: [03:32] Right. And I use, this year, my big example has been roofing because I had to have my roof replaced on my nearly hundred year old house. And that was a project we didn’t need all of the, uh, the events and what not of Scrum we needed to define the outcome was my roof doesn’t leak anymore. Uh, we’re tight and watertight and covered. And it was just a matter of figuring out how to cut for my particularly weird roof.
Dan Neumann: [03:59] Love it. So you did need a skilled tradesman of sorts. But then a product approach, you know, if we’re making something for the market, maybe this is the situation that, that the roofing company or the fence company or the software companies are trying to take, they’re trying to create a product that they can repeatedly sell or get additional customers for that some need there. So it’s not a defined beginning and a defined end for most products.
Sam Falco: [04:31] Right. We, we think we have an idea of what someone might want or need a, a want or need, we can, we can realize, uh, a solution for, but we’re not sure we’re, we’re not always even sure we’ve seen the problem correctly. So we don’t know that we’re actually delivering on a want or need. So we do small products and this is the idea of the MVP, right? That we get something, the smallest possible thing that might work to solve someone’s problem or, you know, uh, they’re, they’re want and see.
Dan Neumann: [05:10] The piece to me that, that comes to mind is just the size. As these efforts become larger and larger, the ability for the customer or the stakeholders to define what they want gets harder and harder. It’s to the point where it’s ridiculous to expect them to be able to articulate it. And the surest way to get that feedback is to start building and delivering an increment.
Sam Falco: [05:38] Right. With a product focus, instead of asking, did we do all of the things, did we do it in the amount of time? Do we do it within budget? We are defining success around user adoption and retention we’re defining around revenue increases or cost savings, that sort of thing. It leads to well it, it reduces waste for one thing. I’ve seen that old study that showed that 80% of features in commercial software packages were rarely or never used. And that was, most of that stuff came out of that old project mindset. Let’s get all the stuff in because we’re gonna, we’re not gonna release except for once a year instead of, again just creating a, um, a vision around what we want to do, creating some small unit of value and then validating whether or not we have achieved what we were trying to do.
Sam Falco: [06:38] Yeah. So the three V’s, I don’t know if that was intentional alliteration. So some vision to value to validation.
Sam Falco: [06:47] Yeah. So we are creating and the, that, that middle one, we are creating value. We’re creating what we think is valuable, but we won’t know until it’s validated against the market. Are people gonna use it? And pay for it if it’s a paid product.
Dan Neumann: [07:05] Yeah. And, and with that assumption that there is some value or at least a hypothesis that there’s value there than getting that increment out or getting a release of it out and then getting the feedback and incorporating rapidly. And of course the feedback loops will vary whether your product is a software product or a hardware product that has a much higher cost of change to it in slower revision cycles.
Sam Falco: [07:31] Yeah, so the three V’s, as you said, and this is the way Scrum.org presents the way a Product Owner should be thinking, start with a vision, create something of value, and then validate whether you’ve created the value you thought you had and something that I found in Don McGreal and Ralph Yoakam’s book, the professional product owner aligns the three V’s explicitly with the three pillars of empiricism, which is what Scrum is based on. Transparency, inspection and adaption. So having a vision creates transparency. If you articulate it, obviously people know what it is they’re trying to create, why they’re doing this thing, what is the the outcome they’re looking for? Again, that’s the difference. A difference between product and project focus is that project focus is focused on completing tasks. Product is focused on achieving outcomes. So we have a vision that is articulated and that gives us transparency. It gives us a basis for every conversation that needs to take place from there on out.
Dan Neumann: [08:43] Yeah, and that’s super valuable when you’ve got a team who understands what the vision is that you’re going for. They have a fighting chance of making more decentralized decisions. If they’re hammering through a requirements doc, you know, bullet 1.2.7 says, you know, the system shell it’s easy to make bad decisions or worse just not make any decisions, just blindly follow, hammering out the requirements. So yeah, it enables some more critical thinking once you have a vision and you’re trying to deliver to that transparent vision that shared understanding.
Sam Falco: [09:20] Absolutely. And that’s one of the reasons why that classic user story format is not just as a type of person, I want to do some thing. It’s also so that I can achieve a particular outcome. So a developer gets this user story and has, as you said, a fighting chance of, of coming close to what was intended or being able to make a decision, Oh well if this is the outcome they’re looking for, clearly they want or probably they want this particular format and to go a little further into the the whole user story topic, what are the three C’s, right ,a card, a conversation and to confirmation. So conversation is important. More transparency, more communication. So then you create something that you hope is of value and now you have something to inspect, you have something you can try to validate those assumptions against. Right? We can give it to customers and if they use it, if they pay for it, if they evangelize for it, we know we’ve hit the Mark. If they don’t do any of those things. We know we’ve got some work to do.
Dan Neumann: [10:33] As you shared the three V’s, it occurred to me that we’ve talked about products but we haven’t actually maybe put a fine point on the definition of what a product actually is. So sure that is important. Right? Let’s go there. Let’s go there. So it is, um, it’s one of those things.
Sam Falco: [10:54] Yes, so you ask what’s a product and they’ll start kind of mumbling around and fumbling the, the, the, the answer. Um, it’s, it’s anything that we could put out in the market and that would satisfy someone’s need or something they want. So that introduces some interesting, uh, I guess scaling problem, uh, and not in the term we use for, for scaled effort, but, um, you know, my, my truck is a product for me. The engine’s not a product, I need it as part of the product. But for Chevy, the engine was a product of whoever they were buying the engine from, et cetera. So products can live in multiple levels of abstraction. It’s something that you’re going to get a customer for, whether that’s a buyer or a consumer.
Dan Neumann: [11:50] Okay. So, Sam, you were saying a product, something that can be put out into the marketplace and you know, ideally that product has got a customer that that is going to hopefully pay for that product. Right? Okay.
Sam Falco: [12:13] Not necessarily pay. Um, I mean, the buyer is a customer, but your consumer may not be your buyer. Your user may not be your buyer, but they’re still your customer. You’ve got to please them as well.
Dan Neumann: [12:25] True. Yeah. So like Spotify model, Spotify business model comes to mind where you can be a free user of that product for a good long time before they trick you into giving up your money.
Sam Falco: [12:38] Right. Uh, and some products, I mean, we might create a product that just has societal benefit but doesn’t, uh,
Dan Neumann: [12:48] For the next podcast we’ll go, why would somebody do that? I’m just kidding. No, not for profits but…
Sam Falco: [12:58] Service and my, you know, the, my water, uh, you know, yeah, I pay for the water bill, pay the water bill, but my, my, my water and sewage, um, those things are, those are considered products. Even though, uh, it’s less about making money, especially for the water and sewage. That’s, that’s my city that handles that. Um,
Dan Neumann: [13:16] Yeah, I worked, I was on the board at the YMCA up here in South bend for a period of time. And certainly there were lots of services and products that we had that were not paid for by the consumers. So let’s bring it back to the product part.
Sam Falco: [13:39] Yes. Product part. So anyway, um, so we, we are, we’re trying to satisfy a want or a need. We are also trying to generate a benefit for the producer of this product. Whether that is revenue, whether that is new customers that are not necessarily buying that product but might, uh, buy other products. Um, whether it is cost savings, right, or, or even avoidance of costs entirely and that sort of thing, it generates a benefit back to the producer. So that’s a product. And so once we’ve created that value to go back to our three V’s and the three pillars of empiricism, the third V is validation again. And that gives us a way to adapt. So there’s our third pillar of empiricism. Now we can validate whether or not, I keep saying that we’ve said it many times in this podcast and I’m actually getting tired of, you ever say a word so many times it starts to lose all meaning.
Dan Neumann: [14:36] I’m familiar with the concept, I really am.
Sam Falco: [14:39] So we want to release frequently and get feedback from, from the market, from the consumers, from the customers.
Dan Neumann: [14:47] Yeah. The infrequent releasing allows so much to build up in the system that what you thought was going to be valuable and accepted by the market is indeed not valuable nor accepted by the market.
Sam Falco: [14:59] Right. Or you miss your market window where it was valuable and now it’s not a, that’s another, another factor. Um, and now there is such a thing as releasing too frequently, more frequently than the business can support. But I haven’t run into one of those in my career.
Dan Neumann: [15:17] I would say that’s not the more common situation, you know, if, if you are a financial institution and what you’re doing is touching your core systems and requires tremendous amounts of back testing, there is too frequently. Actually I, I have run into that in my career where, um, we were a financial services company. We made a product for institutions and they were like, yeah, no, do not give us a release more frequently than once a year. We do not want it, we cannot support it. But the product still continued to evolve on a quarterly release basis. And so you were still releasing, we were still releasing and when somebody maybe was ready to take that release, it was there with the latest features. But from a, um, we did not inflict it on our end customers. It was there when they were writing for it.
Sam Falco: [16:08] Right. And so sustainable pace. One of the principles behind the manifesto for agile software development is not just about the developers, although it definitely is about them. But it does say that everybody involved, including your stakeholders, including your customers, needs to be able to work at this pace. So if you’re constantly bombarding people with updates and upgrades, especially if it’s not seamless, that can be, if that can be a problem.
Dan Neumann: [16:34] It can be. It’s been interesting to see Microsoft’s shift as, of course, you know, we don’t get software and DVDs anymore. And I think the one that gets updated too frequently for me is one drive, cause I keep getting annoyed by on my Mac where it’s like, Oh one drive’s updated one day, like about every week. It feels like, and it’s not that frequent, but Oh my God.
Sam Falco: [16:51] But there’s an example, maybe that’s not a sustainable pace, especially if you have to learn something new. So going back to that financial institution, maybe one of the reasons why they didn’t want releases more often those, and then there’s the training cost that that would incur. And so maybe that was, you know, once a year was enough for them.
Dan Neumann: [17:10] Absolutely. Yeah. It’s not just the cost of shipping the software and installing the software. It’s better when there’s, when there are people that need to be trained for it.
Sam Falco: [17:19] Right. So that’s pretty much the major differences right there between that project focus where you have a you’ve managed towards tasks, you tried to achieve this, uh, this assumption. Basically these estimates of time, budget and scope that were worked out in advance and you check off all the tasks, you get to the end and you assume you’ve got what you, what you needed. And that can work well in a obvious domain knowledge. Don’t go too deep into the Cynefin Framework, but in those best practice worlds are turnkey solutions where a defined process is always going to give you the same outcome or even moving into the complicated domain. You mentioned fencing. Uh, I mentioned roofing. Those are places where a project approach may be valuable or invalid, but when you get into more complex work like software development and other complex product development, a product approach is probably going to do you a world of good because you’re going to generate less waste and you are going to be able to, uh, change course as, as needed.
Dan Neumann: [18:30] Agreed. And prior to clicking record, you and I were talking about the mindset of product and I think it’s appropriate to kind of circle back to that because we could then take a product mindset and still apply it I think to a project focused organization. So where budgets are set up around, uh, you know, you start up, you build a team around it, you do the thing and you end it is still seems like that product mindset can be brought to the a project mechanics type of organization.
Sam Falco: [19:04] Sure. Um, remember a mindset is not just the way we think about something it’s thinking that drives our actions. So you can still be in a project environment perhaps, but have a product mindset and that will change the way you think about what it is you’re building, what it is you’re doing. And it’s also important to note that project is not an athema to agile, especially not to Scrum. The word project is mentioned in the Scrum guide and it is not mentioned in a hostile manner. Each Sprint may be considered a project with no more than a one month horizon. Like project Sprints are used to accomplish something. So each Sprint can be a project to accomplish something. And a lot of Scrum Teams use tasks and they look at those and use them to accomplish something. But you’re doing it with that product mindset of always having a potentially shippable valuable increment of software that someone can use and validate rather than just, here’s our project, we completed this thing. Well it isn’t, it’s an analysis. Great. Can I, can I do something with that? No, and I was talking about this with someone recently and the analogy I used was if you drop off or if I drop off my truck at the mechanic, um, this is the second time I mentioned my truck. I’m not having problems with my truck. It just came up twice. Uh, but if I go…
Dan Neumann: [20:28] You got a nice looking truck. My wife is a gardener and I haul a lot of plants.
Sam Falco: [20:38] Um, but if I, if you take your car into the mechanic and you drop it off and you say it’s making this weird noise and they say, we’ll take a look at it and three hours later they call you and say, come on in we’re done. And you go in and say, great, uh, what do I owe you and they say $150 and you say, what? What? What was the problem? And they tell you the problem. Great. So it’s fixed. Oh no, we just analyzed it for you. You’re not going to be very happy. Likewise, if you do a Sprint that is all analysis or an all requirements gathering. And I had someone to go what’re the requirements for gathering Sprint and after my year stopped bleeding, uh, explain why that was a bad idea. But if you do that and then you bring your stakeholders in and say, you just funded a Scrum Team for a sprint, you spent $75,000 for us to analyze the problem, but not actually take any action on it. They probably aren’t going to be very happy.
Dan Neumann: [21:33] Well, we used to do that all the time in a none agile environment. I mean that was requirements we’d, we’d collect the $75,000 and this is not a, we AgileThought this is the industry, you know, we would pat ourselves on the back for being X percent done when all we have are requirements, we have a document that does nothing and we declare victory and move on to the next phase.
Sam Falco: [21:58] Yeah, exactly. But nobody was ever really happy about that. There was the increasing frustration and I think that is, that is the impetus behind the line in the manifesto that working software over comprehensive documentation, it’s not, the documentation is bad, which is a common misinterpretation. It’s your requirements document doesn’t actually get you any closer to the goal, but you’re calling it a milestone. No, let’s, let’s get a piece of working software in somebody’s hands. And that’s what scrum is all about. Every sprint get a piece of working software in somebody’s hand rather than spending a lot of time defining what you’re going to build up front.
Dan Neumann: [22:35] So for people that are in project land, they can start applying a product mindset. You know, there’s no real barrier to entry. Just it’s, it’s a thought exercise, right? Way to move forward. So thanks for the exploration. Sam. Appreciate you joining and doing that.
Sam Falco: [22:52] I’m always happy to join.
Dan Neumann: [22:54] Are you reading anything these days? What’s got you learning?
Sam Falco: [22:59] I am revisiting um, some old stuff. Um, I am preparing to add to my arsenal of licenses. I want to get to be able to teach the Product Owner course from Scrum.org so I’m studying that material. Um, and the whole idea for this podcast came on the plane today when I was rereading a section with the professional Product Owner. So that is on my reading list. I also just read Malcolm Gladwell’s Blink, which is on making snap decisions and that sort of thing. I did not find it as insightful as Daniel Kahneman’s thinking fast and slow, fast and slow. I still think that book beats anyone else hands down on the subject of how our brains work very fast in certain ways.
Dan Neumann: [23:53] Yeah, I’d have to go back. I remember reading, thinking fast and slow and there are some really interesting things, especially as it related to law enforcement and um, police officers riding in pairs or solo, if I remember right. I think that was in thinking fast and slow. Yeah. Um, yeah, I might have to check that out. In the last episode I mentioned that I’m reading relentless forward progress. It’s basically a tips guide on ultra marathons and hopefully by the time this is aired, I think the book that I’m going to be starting is how to measure anything. It’s really about measuring intangibles or maybe I shouldn’t say, you could save me and listeners 12 hours of our life.
Sam Falco: [24:44] I found it a tedious read and I didn’t find that it, um, yeah, I just, I found that a little tedious.
Dan Neumann: [24:53] Well, I can, uh, I can use some of that ultra marathon training time, which is, can also be tedious and maybe listen to a tedious book at the same time too. Too tedious for the price of one. What happened? Dad fell down and fell asleep while he was running. Well, I will, uh, I’ll share back whether you were, um, you are correct in assuming that that would be my reaction. It’s entirely possible. Well until next time folks have experiment with product versus project. Of course they can email us firstname.lastname@example.org or I think Sam you said somebody reached out to you on your LinkedIn profile.
Sam Falco: [25:30] Yeah, yeah, I saw that that I had a question about the deep dive on Scrum values episode that we did. Uh, the exercise that I had mentioned in there that I did for a Scrum Team, which I pointed him to the Scrum.org a blog post. That is where I had gotten the idea. So it was really nice to hear from someone saying, Hey, I really like what you’re doing. I have some further questions. So yeah, the comments coming, we like to hear them.
Dan Neumann: [25:55] Fantastic. Okay. Until next time. Thanks again.
Outro: [25:59] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts. And the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought-staging.ectfh4-liquidwebsites.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.