Product-centric funding: Incentivize business outcomes, not features
This talk is meant for IT, product, and business executives who are dissatisfied with lackluster output delivered by classic enterprise funding techniques. A detailed business case, paralysis through analysis, and a “one try to get this right” attitude often derail product initiatives before they even start. Learn how successful product teams influence finance, business, and IT to work within the enterprise budgetary limitations while consistently shipping products that customers need.
The talk covers:
Step 1: Identifying opportunity, risk, and estimating investment
Step 2: Monitoring metrics and agile KPIs to report health of product
Step 3: Developing roadmap and continued investment
Watch the talk:
Transcript:
Thanks for coming over. We started this program of Full Stack Fridays several months back. The idea was Chicago has quite a bit of organizational events around design, there's a lot of events around tech meetups and so on and so forth. But there wasn't a loud voice around product and being product-centric and what that meant for organizations. So we started this string of events and now we host it every month and we have different speakers come in and talk about product. And particularly today, we're going to talk about funding products for outcomes. And there's kind of a state in the industry, right? In most large organizations there's a sense of getting too little and spending too much. Essentially, getting half the product for twice the money that you originally planned to invest.
Before I get into prescribing how we should address it and how we should treat product in terms of funding, I wanted to share a specific use case that we ran into... Not a use case, a case study that we ran into. Without naming names, but we started working with a client and the client was somewhat prescriptive in the way that we were supposed to run the implementation of this online banking platform. So it was a big build, quite a significant amount of scope. But they said, "Listen, for us to get buy-in from the business and to get funding for this build, we need to show the business what they're going to get for it, right?" And that's pretty typical. You need to convince the business with a BRD or a business case. So they said, "Let's do all of the design upfront," because what could go wrong? So we get started with design in Q1 of 2017, and we keep working for quite a while. Now by Q3, we have this gorilla on our hands, right?
It's 400 screens, detailed use cases, detailed workflows, every single interaction in the application actually mapped out, acceptance criteria, humongous files and a ton of assets. And then we take a little bit of time because we now need to estimate this beast. So the technical teams are actually looking at the mock-ups of all of the work that's been done today, and they're trying to put numbers around it because we need to quantify. All right. So now we designed this, it took however much money to do the design, but we need to do the implementation. So then we get started in Q1 in 2018, started building, and then we realized, "You know what? We need to make some changes." Because typically, when you do design and if you disassociated design from implementation, you're actually baking in assumptions without any type of validation, right? Or any type of learning, build, measure, learn loop in the process.
So now you need to make revisions and so you have to kind of halt the development. You do the design revisions, then you need to rebuild some components because you've already made some assessments and some implementations on the technical side. And all the while we're doing this, the product that is actually growing, because we're not able to actually ship working product out the door. So there's zero value created for the business. And even though we're maybe course-correcting for product and the depth goes on a little bit, but it's still mounting. And then by the time you actually get out to a working product that you can get into UAT, it's no longer a gorilla, it's a Godzilla, right?
And the problem is that you have all of this acceptance criteria you need to go through now, you haven't gotten this in front of the users, but you've spent all of your money. And good luck raining that baby in, right? So it's gone. It's gone. And very likely, you got half the value for double the budget. And what's interesting, we looked at that specific engagement and the client is fundamentally happy with what they got. So we didn't drop the ball on the delivery, but we looked at the effort taken to get there. And it was two years worth of work. We could've done that in eight months. If we ran that as an integrated cross-functional product team that did design and implementation at the same time with learning along the way, we would've compressed that timeline and compressed the spend. So the point I'm going to talk about and kind of the objective of this talk, right? Is we need to look at how we fund things because this risk-averse, design first or business case first, BRD first approach, it ends up spending more money and delivering less value for the business.
So we need to look at how do we incentivize outcomes and then how do we structure funding methodologies to actually allow the teams to do what they need to do in this type of approach. So the first part is, okay, so now we're going to start building a product. How do we help the team understand what value is so they can kind of self-govern, right? And they can point the product in the right direction. And there's many tools for it. A good example is Groupon, or a good bad example. So Groupon has changed over time, but I remember when Groupon got started and got big, one of the things that you could do is as a business, because say I'm the customer of Groupon. So I'm the business that is going to list their services or products on Groupon. And the premise is that if I sell five breakfasts on Groupon, I can sell it at a much lower cost, but hopefully I get some customers through the door.
So even though I may be losing money on that initial transaction that I do through Groupon for the group purchases, long-term I should be getting a sticky customer that comes back. So it's an advertising play, right? Discount and then retain the customer. What actually happened in this instance with the product was that it created a completely different behavior in the users. So they created coupon hunters, which would go to a specific restaurant or make a specific purchase, never to come back to that same brand or organization or service. So the businesses were learning that, "Hey, we're losing money on that initial interaction, Groupon's benefiting from it, but as a customer." So the value and the product is actually misaligned, right? It's pulling in two different directions. So we want to prevent that. And a good way to make sure that that value and product is aligned, is to kind of go through this journey of using a variety of exercises as well as kind of delivery patterns as you build software. Ultimately, we're talking about software, right?
So we go through exercises like service mapping or building a service blueprint. We go through ideation. Then we take a specific idea, we do lean requirements around that idea to identify what features support the outcomes that we're looking for. And then we put in specific metrics that we can track along the way to make sure that the product is actually hitting the mark. I'll talk about those in more detail, actually using a specific case study of a client. Schumacher Clinical Partners. They're an organization, so what they do in layman's terms is, they have 6,000 doctors and nurses, and they staff the doctors and nurses into hospitals. Essentially, anytime you're running ER or whatever and you have a shift that changes and a doctor gets sick, you need to staff that shift, right? ER can't just go, "Eh, you know what? We're understaffed, we're not going to do it today."
So what they do is, they manage that demand and supply across hospitals, that's their value add. Now the problem they were running into is that they were running all of these processes manually. Excel, documents, calling, SMSes, right? And you imagine needing to orchestrate 6,000 doctors and nurses across hospitals all around the US. It becomes a nightmare and obviously an operational inefficiency. So we started by doing a service blueprint. And for those of you that haven't done blueprinting or a service blueprinting. The whole idea is taking the business and mapping out all of the touchpoints that a customer has throughout the life cycle of the engagement. And not only mapping them with the front lines of the business, but also mapping it across the different verticals of the business. So accounting has an impact because they need to issue an invoice, and then there's front end people that need to interact with the customer, and then there's back office people that do the paperwork, and so on and so forth.
But the whole idea is that you map the interactions of the customer throughout the different, essentially, departments of the business. And then you look at what areas can you do automation? What areas can you introduce software to actually introduce operational efficiencies or new revenue opportunities, right? Actually, sell more things, sell more service in the business. And we found this idea of working with a client that instead of doing all of the things manually, what you could do is you could build a mobile application and a web app, and you could actually do scheduling and communications through a digital platform. Instead of using Excel, why not do all of the orchestration through an app? So we story map what the futures would look like, what the epics were for this mobile application and admin interface.
And then we also mapped out, which is important here, not only the value for the business, so how can the business be more effective at doing what they do, but the user value. So where do the doctors win in this instance? And then we overlap those two priorities. That's what you see with the multicolored sticky notes. And we said these stories are actually the fundamentals of the application. We definitely need to get these out the door in the first version, because if there's business value, but there's no user value, there's not going to be adoption. So the business may be like, "Hey, we're very efficient." No doctors are using the app. Big whoop, right? And so we ended up building the application and it was a short initial bill just to get that MVP out the door. But we always, as we continue through the build, in the product charter that we created for this product build, we always looked at the outcome as the main thing at the top, and then all of the different dependencies trickled down from the outcome.
So you still need to evaluate integrations and risks and everything else, but we looked at that business and user value, the outcome, as the driver for the product strategy. Now throughout the build, right? And I'll get back to Schumacher in just a second. But throughout the build, you also need to have very specific measurable and kind of achievable results that you're aiming for, or outcomes. Whenever we start on a new build with our clients, we run into requests like, "Well, we want to gain market share." And that's fine, and we say, "Okay. How much? How did you guys come up with a number?" And then the more you start chipping away at it, it's like a fake metric. There's no way to justify it, no way to quantify it even. It's a great desire, but it's not really an in-state.
So we always say, "Let's look for very specific material things like, 'Hey, can we do a state change? So I did this in Excel and now I don't do this in Excel, and now I do it digitally. And then can I look at the time to actually assign someone to shift, and it would take me on average 15 minutes, I took it down now to seven minutes.'" Very simple metrics, but fundamentally, you can use those to then justify the investment into the product. And this is kind of my pet peeve, right? As with that initial example of doing design upfront and then implementation, if you don't have something in production, it's worthless. It doesn't matter how much time you spent, don't matter how brilliant you are, don't matter how great it looks. It is worthless until it hits prod. Because when it hits prod you get traction and you get user feedback. And without user feedback, that product may as well be a flop.
So with Schumacher, what we did was we made sure that we had very, very small, incremental releases going to market frequently. Initial build, obviously, it takes a little bit longer, so we spent four months doing the first concept and the MVP application. But then after that, we had very, very rapid and frequent releases every couple of weeks, every couple of months and so on and so forth. The way we've been able to do that though, is when we implement analytics into the product, and we made sure that we tracked all of those measurable outcomes as hard data in terms of adoption. So we said, "How many shifts are getting filled through the product? What is the engagement level? What is the adoption level of the product?" As we were making these releases.
What then the business did was they were taking this data and the product, they would go back to the board and they would say, "Well, we just spent half a million dollars for this and here's how the metrics changed. We need another half a million dollars to invest into the product with anticipated changes like this." So it becomes a very, very, kind of nice and tight coupling between investment and outcome that you're seeking. And there's obviously then accountability and the team is enabled to do what they need to do. So to kind of summarize the first part, right? You started out by not really knowing what you're going to be doing. You go through these exercises that I talked about, like service blueprint and story mapping and ideation and benchmarking to figure out which idea or product you actually want to invest in. And so then you build your story map, you go ask for investment and you get, we typically call it micro-funding. You get micro-funding for three, four months to build your MVP.
Could be a prototype. Hopefully, it's something that you can productionize. Hopefully, you can distill it to a small lessons, maybe a friends and family release, but you can get it out to production. Now after, after it goes out into the market, you go and look back at your outcome quantifiers, right? You look at your metrics and say, "Okay. Based on the assumptions that we made when we started out on this journey, is the product actually hitting the marks that you've established for it?" And if it isn't, well, might as well purge it. Because the worst thing is to keep dumping money into something that's not working, right? But maybe you learn that, "You know what? I need another loop." So you know what? Maybe we have some indication that this can be successful, but we need additional investment to build more features. Because there is something to be said about a critical mass of functionality that you need to build into a product before it becomes market viable, right?
So maybe you go around it one more time through that loop, build, measure, learn, and then hopefully it's ready to jump off the cliff and go to market and then you launch it. So that's theory around, okay, how do you quantify value? How do you get product out the door? And that all makes sense, but you still need to then go back to the business and the CFO or whoever else is sitting and funding these things, right? Like, "Okay. How much does this cost?" So you still fall back. You can have the most brilliant way of building product and getting it out the door, but the funding question of actually planning what the business is going to spend that year, it's inevitable. It doesn't matter what kind of business you are, you can be a software shop or whatever, but you still need to plan.
So we need to look at the right structure to do that and what are the different structures as a product goes through the life cycle of a product. So from being a new MVP type product to being a mature platform that you need to continuously fund and maintain and build. Right. So let's talk about the problems, right? Typical issue in typical enterprises is that to build anything, to start a new venture, to build a new product, to replace an existing platform, there's usually a BRD or business requirements document or a business case that needs to be built. And the fundamental reason why it's done is not really for the outcomes, it's because it's meant to mitigate risk. And the reason why it's meant to mitigate risk is because typically, technology and business are separated. Typically, in large enterprises this is the case.
So business worries about the customer, IT worries about delivery. And if you think about it, and from our engagements with our customers, we see this all the time. At the end of the day, there's a conflict of interest. Because the way that it's structured and the way that the reporting structures are built, IT is looking to deliver the scope that they committed to in the BRD, business was looking to get most value that they get out of the dollars that they just spent. And so again, they're pulling into separate directions instead of being aligned around a central objective.
Now again, there's this, right? You get less than you plan because everyone's trying to protect their own domain or their thiefdom. But then there's another artifact that spawns off of this is because the most talented people get tired of dealing with this shit and quit. Because they don't want to be in-fighting or being political about building product. And when the business is pulling in one way and IT is pulling into the different direction, it's very, very hard to build cohesive teams because they become political, again, they have a lot of conflict in-house. That's why Fortune 500s have so much trouble recruiting and retaining good talent. And so the new trend and the new direction and the ideal way of doing this, right? Is building product organizations. And hopefully, most companies are picking up on this and starting to move and have the shift where it's no longer a CIO, it's no longer a VP of business, but it's a CPO and your product is centered under the chief product officer or however else, chief customer experience officer.
And then everything trickles down from that. Funding comes from product, outcomes are measured based on product, the teams are cross-functional and they can cover all of the domains inside the team. So you have cross-functional team that owns design, product management, and engineering. Everything's baked into that single team. Let's go back to funding for a second. When you start talking about funding, right? There's typically two types of products that you may be building, right? There's a new product or a new venture, and then there's a mature product that needs to stay evergreen, and likely, even the new opportunities eventually need to become evergreen products. So even if you go out like Schumacher, you go out and you build that scheduling application, scheduling platform, now it is the expectation of the customer that this thing is going to be permanent, right?
So there has to be roadmap, there has to be continuous investment for that product. You can't just build, put on a shelf, good deal. One. Right? So new opportunities either get purged or they become evergreen products. And so when thinking about funding, whether it's a new product or an ongoing product, you always need to think about continuity. And if there is no continuity, then just scrap that product altogether, because otherwise you're going to deal with legacy. Using Schumacher again as an example, the way that we use the funding model there was we said, "Listen, we want to build up trust and buy-in from senior leadership from the board that the money that they're spending on this new initiative, completely new build is actually worthwhile and that it's driving value.
So we have these micro-funding sprints of three, four months at a time. And then eventually, there was perception of this product actually taking off, right? It actually started driving ROI, they saw adoption, they saw efficiency and so on and so forth. And at that point, you need to scale that up and actually make it a mature product organization where you have multiple workstreams, or we sometimes call them investment themes that are supporting multiple tracks of work. I don't have a visual, but I always like to say it's like [Voltron 00:18:42], right? You have multiple cross-functional product teams that can assemble into one, but they run scrum of scrums, but they run independently, they can build their own product tracks, but ultimately, it's all for a single product.
Now before you can get into that model though, you need to build up trust. And usually that's the main sticking point when organizations start to shift their funding model and their operational model into this investment theme roadmap. Because without demonstrating trust in predictable outcome, it's very hard to have enough confidence to say, "You know what? We're just going to put $2 million, earmark it for this team, and they're going to get it done." Without knowing necessarily what the outcome is. Another case study I wanted to share was work we did with Grainger. And Grainger went about rebuilding and redesigning the way that they were going to sell their products online. So just so you guys know, their online channel is a $5 billion channel. $5 billion a year sold online, another $5 billion sold retail or catalog. Now obviously, that is a big undertaking and a big risk point. And so what we did with them, we built a prototype, a data-driven prototype in three months, and then we ran that prototype through user testing and validation.
And so we went through user studies, essentially, [crosstalk 00:20:04] eye tracking, random through competitor products, through Grainger's .com site, through the new product. And at the end of the day, what happened was that the validation built enough trust for Grainger to actually invest and scale up into full product org. And so we ended up going through a full build experience of getting the e-commerce engine up, getting the mobile up, establish those multiple teams for multiple tracks of builds, right? So there was a search team, front-end team, performance team, and so on and so forth. And we ran it off of several different backlogs in our Jira instance. We always looked at what are the customer needs? So what is going to drive value for the customer? We always tracked product debt because we knew that anytime we were making sacrifices that was increasing our product debt. By the way, there's a good talk that Chris does about product debt. And we're probably going to be circling it back again, but if you guys haven't been in the previous sessions, that's a good one to check out.
Then we always look at the business needs, right? Again, talking about how does that value align across those two? And we always track technical debt. Now sometimes your backlogs may overlap. So customer needs and product debt sometimes is going to be the same thing. And vice versa, right? Product debt and business needs may overlap as well. As you're kind of looking at funding and building product, as you look at these backlogs, we always say you need to look at, is what you're going to be building feasible, ready from a technical standpoint and is there value? Again, back to map to the original metrics that you established. We also would like to, when doing prioritization, we like to look at the quadrants of high business value versus low business value, and then layer complexity on top of that. So that you can look and say, "Well, there's high value, low complexity, that's an easy one to prioritize. Versus high complexity, high value, that's a harder one to get done, but it may be really valuable."
The reason I was showing those slides and in terms of prioritization is, when you establish a product team that has predictable output and you know their velocity and how quickly they can get product out the door, you can fund a theme and then you can map your stories to a theme and very easily predict how much money it's going to cost you to get through your roadmap. So instead of using BRDs and the lengthy kind of business-oriented approval process to lock in funding, you can just allocate a team and you say, "My team is going to cost me a million dollars a year. I know exactly what their velocity is, I know what my backlog is, I have estimated my backlog and sized up my stories. I can now simply predict that the business is going to get the following functionality by end of the year because I know the velocity of the team."
So it's a much more natural, much more organic way to allow the teams to self-manage and to deliver value instead of moving that requirements and that risk aversion upfront. So much more sophisticated way of building and funding product. And a predictable way to get more value for less spend. That's it. Thanks.
About the event:
Full Stack Friday is a monthly, meet up hosted by Devbridge at our Chicago headquarters. We get together to indulge in a delicious pancake breakfast and talk shop. We bring in guest speakers to present talks focused on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.