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:
We're here to talk about funding products for outcomes. The reason why this is interesting for me and why I've spent a significant amount of time thinking about funding and how to make products successful is because this has fundamentally to do with organizational design, right? And how do you build companies that are able to use technology and that are able to be nimble and maximize the benefits that technology can drive as they build?
Now, before we get into the how things should be done in an ideal world, right, I want to share a story or a reality, I suppose, of how products usually transpire in an organization that wants to leverage technology to drive results. Because of how risk aversion is, I would say, prevalent in larger organizations, and this is actually a real example based on work we did with a financial institution, folks tend to fall back on trying to lock in all of the definition of what the product is going to be to clearly illustrate how the product is going to work ahead of time. This is related to the way that the money gets allocated to the product, because you need a business requirement document or a business case to be submitted in the organization for funding to be unlocked for whatever the product is.
In this particular instance, this is an example of an online banking system that we were building. The business had allocated a certain amount of money to get all of the designs done. So design started with Sprint 0, and we were starting to design all of the workflows and all of the experiences of this online banking system. It took us essentially a couple of quarters to get all of that work done, right? By the time we were done, it was a gorilla in terms of the number of assets that we had generated was around 400 screens with workflows and acceptance criteria and interaction models and things like that. So half a year is spent at this point. And then implementation starts to actually take all of what is happening on the screen, and to put that into software, into working software.
Now, based on the designs, another estimate was created to assess the complexity and the investment that is necessary. Based on that estimate, the team is now getting started on the work.
Here's the thing that happens though in most of these scenarios is that the moment you start building working software... By the way, in retrospect, I can say that this is not the way that we typically work, but in this particular instance, we were forced into this type of, I would say, waterfall-ish delivery. So design was done in a linear fashion, then we were able to get into development.
We used iterative development, but again, because we didn't have that build, measure, learn methodology in place, we very quickly discovered that we had to actually revise a lot of the assumptions that were made during the design phase, because no real software was in front of users. The moment you shipped a component and you exposed it to the users, you realize, "Well, things needed to change."
So based on the changes, then we had to rebuild the UI, and there's some service changes that were impacted as well in the backend. So all of a sudden, you're managing this set of 400 assets to refine, and now your budget is being impacted and you're actually accruing product debt, right? So all through design and all up until these revisions are being made, you're accumulating product debt based on the uninformed decisions that were made earlier on.
What transpires, really, is that you essentially spend two years to get into UAT, right? So user acceptance testing. These are two years where, again, you're accumulating product debt. You're not in production. You're not recognizing the value. And this thing is a beast now, right? Because UAT was not happening along the delivery. There's a lot of workflows, a lot of acceptance criteria that needs to be validated, and things have changed along the way. And by this point, the things... It's out of the bag, right? The project has escaped the original estimates, the budgets that were established. So from the business perspective, you've created less value and spent twice as much money. I suspect for most that are watching, this is a relatable reality of probably most of enterprise engagements that happen out in the wild.
We don't want to continue doing this, right? We're not P. Diddy. We can't just throw cash at the problem all the time. So I've always been a big advocate for looking at the funding methodologies as well as the organizational structure as an area where we can fine-tune these dials and actually use all of the best practices from product development to ship value to market much, much faster. We'll look at that in a second.
But one thing that we need to kind of get out of the way right in the beginning is that classical funding techniques and in general the way most procurement and enterprise organizations work and even the finance operations work in large enterprises, funding is used to manage risk, right? It's means to say, "Well, how much do I get for paying this much?" What we've learned is that effectively funding, and I'll talk what effective funding looks like and what it means, it actually influences team behavior. So if you fund the teams correctly, if you give them the right liberties, teams can produce much more value and much faster. Some companies are moving in this direction and changing the way that they're doing funding and the way that they're even changing organizational structure.
Now, there's two kind of points or two parts to this presentation that I want you to think about and then remember at the end of it. But we want to make sure that we want to enable the product team to deliver value, right? In the first section, we'll talk about how to enable the team to deliver value. In the second part, we'll talk about how to structure funding to, again, incentivize the team with the right behaviors.
In terms of value, right, there's a company that most of you will know, Chicago-based company, Groupon. It's an interesting organization that can be used almost like a case study of how sometimes user value and business value are disassociated from one another.
In this particular instance, I want to tell you a story about a pizzeria. We used to do a lot of work with a large pizza franchise in the past, and they were using Groupon, right? The idea behind Groupon is that I can offer a pizza through Groupon through group purchasing. It'll get promoted on Groupon, it'll get additional eyeballs and traffic, and then people will buy this pizza at a discounted price.
Now, as a pizzeria owner or a franchise, I want to get my product out there and I'll get eyeballs. I'll sell it cheaper because I know that this is a marketing channel and a vehicle. The idea is that I'm going to retain some of those clients that I acquire, right? So it's a good channel for me to do customer acquisition and hopefully, I can make my money back after I sell more pizzas after they come back. Because I do make pretty good pizza, if you ask me.
However, what has happened with Groupon, as the product was evolving, right, and as the system was being built out, the system actually created a new type of user. So Groupon created the bargain hunter, and the bargain hunter never really cared to return to the businesses that were promoting themselves through the platform. So you had this disassociation, right, of business value versus customer value. Because for the business, well, that was for Groupon themselves. That was a great idea, right? They were getting all of this traffic, they were getting all of these customers that were paying into the platform, but they weren't actually delivering value to their real customer. Not to the end user, that's buying the coupon, but to the pizzeria, to the franchise.
So it's incredibly important when planning products and setting up products to succeed, it's important to align the product and outcome, or to kind of the intent that you have to the outcome. There's a few tools that we use, and I won't go into detail into all of them right now. These are kind of just areas that you can explore. We have a lot of white papers around all of these.
Typically, when we work with an organization, we do a service blueprint to identify how the service actually looks like from a customer perspective as well as from all of the areas in the business that are impacted. When you carry out a service blueprint, you typically will detect that there are opportunities in your service, whether you're providing loans for customers or you're selling pizzas or you're filing taxes for someone. In your whole service blueprint, you will see certain opportunities and gaps where maybe an opportunity for software exists.
We then take that, kind of the opportunity, and we run lean requirements to identify a very high level kind of roadmap for what that product will look like, as well as identify the success metrics for the product, right? This is an important area, right? Where the success metrics they need to kind of account for what are the intentions for the business, as well as the intentions for the end customer, because both should win in the interaction on the product.
Another real story. We have a client in the healthcare space and it's an interesting client. What they do is they do staffing for hospitals, right? They do staffing of nurses and doctors. It's a really interesting business, and it's even more interesting in the current time or current climate of what we're going through right now. But as this business was providing this service to their clients who are hospitals, they were doing a lot of manual facilitation in that process. So they were using Excel sheets, they were using phones, SMSes to talk to the hospitals to figure out shift requirements, how many doctors should be in a shift and so on and so forth.
What we did with SCP is we actually mapped out what that interaction looks like. This is the service blueprint that you saw before. But we mapped out every single touchpoint from a perspective of a doctor, every single touchpoint from a perspective of a scheduler, every single touchpoint from the perspective of every single department in our client's organization to understand how a transaction transpires through time to fill a particular shift, right?
As we were doing this and as we were building this, we quickly understood that there were gaps. There were, I would say, manual steps in the process in which our clients were... Well, they were dealing with a lot of churn to get this done.
Essentially, the team came out of the exercise and said, "Well, there's value that we can create by introducing process automation in context of scheduling," right? Filling shifts, process automation could be a mobile app and some type of tooling around the mobile application to pair the nurse or the doctor with the shift that needed filling.
So the team went through a lean requirements workshop, and as I was giving you the example with Groupon, they looked at user and business value around the different features that were identified in the lean requirements workshop to then kind of map and understand which should be prioritized from the initial version, the MVP version of this product that needed to be built. The initial MVP version was essentially a communications application for their workforce. So all of the nurses and doctors could communicate and chat and discuss the available shifts, excuse me, with schedulers at the client.
Now, what's important to mention is that an application is not an outcome, right? So this is we've made a good effort so far to build an MVP in a few months to retrofit a product into an opportunity identified in a service blueprint.
But the team still needs to understand what is value, right? So we made some assumptions along the way of what should value be. But we also need to quantify it. Some of the best practices around quantifying what value is for product teams if you have a cross-functional delivery team, is you need to define outcomes that are specific, measurable, and achievable. It's incredibly important. You cannot make this ambiguous. You cannot make it too aspirational. It has to be specific. It has to be measurable and achievable. So that when you are releasing this initial product that is funded a certain amount of money, you could very, very specifically articulate the value that is being created based on the data that that product is collecting. I'll show you in a moment of what that looked like.
As the application rolled out, we actually went through this initial phase of... It took us four months to get the application out in the market. We collected data. Based on the data, we then revised and built additional functionality. All of those red dots are production releases that went out. And we were learning along the way. We were measuring the impact the product was making on the client and their end customers. And then the client was continuing to invest additional funds to further revise and refine this product, again, to drive the outcomes that were desired for the business.
At the end of the day, right, software and production is value. Only when you're able to get something out in production, it becomes value. So when I gave that example of the online banking platform in the beginning, that organization, it took them two years before any value was recognized. So that's two years of committing to spend, of committing to an effort without recognizing any value, without measuring any of the impact that this investment is making. In our mind, that is way too long. There's too much risk being carried in that type of methodology.
Now, particularly with this messaging platform, what was really exciting was that we implemented analytics from day one. We used Mixpanel analytics in this particular product. But we looked not only at pretty kind of, I guess, common things such as adoption, number of downloads, messages that were being exchanged through the platform. But we also were looking at specific business outcomes that the business wanted to drive through this investment, right? That specific outcome in this particular scenario was how many shifts are actually being filled through the platform. Meaning that the original intent of smoothing that interaction cycle of making the transaction of filling a particular shift, lower effort, right? So lowering the overhead, allowing a single scheduler to facilitate more work through automation and through this product.
So we monitored this and obviously, this has paid off significantly. What's really cool is that this application is being very actively used right now, as obviously the demand for medical professionals is so high. Our client is really well positioned with a very competitive offering from a technology perspective as they work with hospitals around the United States.
Now, so just to recap what we talked about really quickly, right? We start by not knowing what we need to do. We carry out some of these exercises around ideation, research benchmarking, create a service map. Define the outcomes, right, that we want to drive. So we define that this is actually an application. We have the metrics that we're going to use to measure. We build in very short increments, short iterations. We measure along the way. We microfund that initial investment. And then we check the definition of value. We look at our metrics and we go and say, "Okay, do we just purchase this thing? It's not worth it. We invested a quarter-million dollars, but you know what? At this point in time, we need to kill it." Or do we go, "Well, no, but we don't have conclusive evidence that this thing should be killed. So let's reworkshop, let's invest an additional incremental amount to see if the product is going to generate value." The moment that it does, well, it goes out to market, you release it.
Again, we talked about funding being used to manage risk. What our claim is is that the funding sequences should be made shorter, at least in the initial phases of product development, because that allows you to mitigate risk while not impeding the process that you use to build product. So you can still build great products. You can still use agile and iterative product development and be customer-centric without sacrificing risk awareness or risk aversion. Yeah, that's part one. So know the value, measure the value along the way, and that will then inform, obviously, the organization on how to behave when the product is being developed.
The thing that's really important too, and I mentioned about behavioral change related to the structures that are used and having clear outcomes defined, having the liberty for the team to fail and make mistakes, and then course correct, it allows the team to take ownership. It incentivizes the right types of behavior, the right types of culture for the cross-functional team that's building the product to make those decisions. So they don't need rigorous management structures or overhead for them to be successful. Which is really the ideal target state, right, for independent teams delivering great products.
Now the second part is how much should you really invest. Even if we're talking about these product development initiatives, how do you determine what that amount is, how large it should be, how long you should go. So we really need to talk about this funding models and why they don't work and how we can do them better.
As I said before, typically the business requirement document or the business case, they're used to manage risk, really. That is the fundamental reason it's... It's a way for that case to transpire through a large enterprise and for multiple people in the enterprise to understand the value before funds are allocated.
What typically happens too is that the organizational structure implies the need for it. Here's what I mean by that. In a classical organization, business and IT are two separate organizations. This goes all the way back to the way that companies were shaped and the way that technology was injected into the enterprise. But essentially, IT has historically been a cost center. IT has not really been a product organization. So the business usually defines what they need done, and then IT or technology needs to deliver it. The business has the money and controls the scope, but IT's neck is on the line to actually make things happen. So what ultimately happens is there's a very, very significant conflict of interest, because it is a combative relationship at the end of the day, where one party wants to squeeze out the maximum value out of the other party without really any reward attached to this other party performing well or performing poorly in other instances.
You know how this works, right? The siloed approach. The definition, the funding, everything happens on the business side, and then IT takes it over. They do the implementation. But it takes 12 months or in many instances like I showed before, maybe sometimes even 24 months before any type of value is being delivered to the business to recognize. So we know where this goes.
Another artifact of this type of scenario is that the best people for engineers, designers, product managers, they don't want to work in this type of ecosystem because it's a lose, lose relationship, right? It's a lose, lose relationship. If you do well, well, you're just meeting expectations. If you do poorly, you failed and you get punished. So there's no room for incremental learning or improvement.
The response to this from the industry in general, right? From the technology industry and what we see in market leaders and the way that we run our teams as well. It's a product-centric organization where everything around the product is centered around a single executive and a single axis. So you don't have this distribution of interests, and essentially, you allow the chief product officer to fund specific product initiatives, and the team owns the delivery. They own the outcomes of the specific investment.
Typically what that looks like is you have cross-functional teams that have the three disciplines necessary to develop products, such as product management, product design, and software engineering. These teams can look at any initiative, any build or anything that is being done. And a new opportunity eventually needs to become an evergreen product or it needs to be killed off. A mature product also needs to be kind of looked at how do you fund the mature product.
As I was showing with the previous example of the mobile messaging application, which later evolved into much more, any new opportunity that spawns off in the organization, it needs to use this microfunding approach where small incremental funding is used to gauge the success of that particular engagement. And as value is realized, and if it is proven using data, then that team can be scaled up or that initiative can be scaled up. And the funding model then changes from microfunding into theme-based funding.
Again, I was showing that example, but we essentially used half-million dollar increments to gauge the effectiveness of the software that was being built and checking for the outcomes. If the outcomes were met, additional funding was being invested into the product.
Now a mature product. Imagine a piece of software that is being used by thousands of customers. It has multiple pieces of functionality, multiple components that are being licensed. Maybe it's a software as a service product. So at that point in time, you have to look at it in a little bit different way. You have to look at what are the different tracks that that product needs. Again, in our pretend scenario, we could have a mobile application track, we could have an administrator interface track, we'd have data and services track. Each of those tracks has teams assigned to them and has predictable output associated with each track. So if we have a team, we can gauge the speed at which the team is doing the work, and we kind of know how much money we need to give the team in any given year for them to be able to produce meaningful results out of that particular product track.
One thing that I like to say is in terms of timing and duration, never ever go longer than six months with any type of release. I'd rather look at this as kind of the strategy that is being used to build space stations, right? Or international space stations. You take small components and you ship them up to the orbit, because it's a more cost-effective way as well as it is much more a risk averse way of building a large initiative. Never go for the Death Star. It just simply does not work. So press down those iterations to get the value out, because otherwise, you're dealing with a lot of risk.
The other side effect of that too is if you're working on a really large program and you're not able to actually segment it out or break it out into components, the accuracy of managing that large program drops significantly the larger the initiative. There's something to be said about rising level of complexity when you talk about complex systems, and there is a point of no return where the increase of complexity simply kills your accuracy in assessing what the effort is associated with that particular effort or with that particular program.
Where you want to get to, right, is you want to get to predictable output. You want to be able to have predictable outcome from the team, from a particular product team, develop that trust, and then you're able to fund that team predictably as you go forward, because you know what you're going to get for a certain amount of money. So instead of using this preemptive estimation and preemptive risk mitigation, you have proven delivery record, and then you invest based on the proven track record. That removes a lot of the overhead that you typically would encounter in those scenarios.
Another great example is Grainger, one of our clients. We built a product for them, which was kind of like... It was a pivot in the business model for Grainger, and they wanted to test out a new way to do e-commerce. What we learned or what we used to make this engagement successful was we actually built an initial MVP and then we did user testing along the way.
I like this already because it has different descriptions. What I'm trying to sort in my head, it puts them all in order. I like that a lot. Okay, so-
You saw the actual testing of a data-driven prototype happening there. But we had certain assumptions around the outcomes that we wanted to drive out of a different engagement model for Grainger. There were assumptions that we needed to validate through this prototype, and the prototype was funded using these microfunding methodology. The assumptions were validated and then Grainger scaled out the delivery to multiple teams in multiple tracks. And then they used theme-based funding to have all of these different individuals and all of the different teams contributing to different channels of the product.
As you plan something like that, right, as you get ready to scale out a product into multiple tracks and as you plan on funding multiple product tracks, you really should be thinking about various or multiple backlogs and multiple story maps that you need to be actively tracking. Because probably there's a set of customer needs. There's probably some product debt that you're constantly incurring. There's business needs that are maybe not necessarily directly related to the customer, but they're operationally important to the business. And then there's also a technical debt that should be tracked.
Now, again, some of those, as you can kind of see those tiles, some of them, you can see that some of those stories actually overlap multiple categories. Which is fine, right? Sometimes customer needs align with business things as well. So you look at those backlogs and you look at the technical readiness, you look at feasibility, you look at the value and priority for the business. And based on the intersection of those three categories, you then determine what qualifies for investment as you look at your roadmap of the product, as you continue putting money into the product.
One of the last things I want you to kind of remember as a takeaway from this is that as you are prioritizing, always look at high business value and piece of cake kind of implementation stories, because that's the sweet spot for getting a lot of bang for your buck. And then also, look at the quadrant that deals with more risky opportunities, but also high business risky opportunity. So it's almost kind of like a hedging strategy to pick up some low-hanging fruit, as well as some of the long-term business value driving stories from those backlogs to continue advancing the product.
And obviously, as you think about managing this, as you think about managing a product roadmap, always use typical agile metrics to forecast what investment you're going to need to drive what outcomes. This is a very typical burn up chart. I'm not going to go into the detail of how this works, but the idea is that if you have predictable velocity, you can very quickly identify how much money you're going to need to reach the desired functionality set, right? So there's a way to get more value and minimize the spend if the funding techniques are accurate and if the team is owning the outcomes for the delivery that they're making.
The takeaways, right, from this presentation, really. You want to use those lean discovery methodologies to define what the outcomes are. You want to have them really clearly identified so that the team can self-govern. That is the number one thing that is important. Specific, measurable, achievable outcomes. The team is able to identify what they need to be working on in small increments, and they're self-governing. Because this type of structure, this type of model of teams incentivizes the team to take ownership of the outcomes. They don't need to be managed if they're set up with this full ownership.
On the other side of the fence, you need to use various funding techniques based on the maturity of the product. So for early-stage products, you use a certain funding methodology. For more mature products, you use theme-based funding with predictable outcome based on each theme.
Again, organizational structure implies the success of the team. So if you have a highly segregated, highly distributed organization that is not operating as a product-centric company, as a customer-centric company, this will not work it. Agile and all of these value driving methodologies, they're a great process, but the process does not create the value. It's actually the cultural changes and the organizational changes that need to happen for these methodologies to work and to drive value for the enterprise.
This is what we want. We want predictable output, frictionless funding, and fast value to market. That concludes my presentation. Yeah, hopefully this was useful. Please send me feedback if you can. We'll send you some feedback forms. We'd love to hear what you guys think. Thank you all.
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.