The following is adapted from Build What Matters.
Earlier in the book, I told the story of Opower’s color-coded roadmap, which highlighted the inconvenient truth that our willingness to say yes to inbound feature requests from RFPs was perpetually pushing out our more innovative and strategically valuable work. This is the story of how we finally broke the cycle.
Every B2B SaaS company dreams of being able to build a product, make it available to customers, and have them buy it and get value from it without having to do any customization or product additions to close new business. With excellent product management and salesmanship, that is achievable within most industries. When selling to regulated utilities, on the other hand, it is not. No matter how robust the product capabilities, there will always be some idiosyncratic customer need that has to be accommodated. To have a hard and fast rule of saying no to all feature requests would have cost Opower almost every single deal we won. In effect, we were selling a square peg to fit a differently shaped round hole each time, and the peg had to be modified slightly, or it just wouldn’t fit. That burden fell on product development.
The difficulty was in making the right decisions about when to say yes to a feature request because it was a modification that was needed and when to say no because the deal could still be won without it. Enterprises are notorious for putting “the kitchen sink” into their RFPs in hopes of getting vendors to solve a slew of problems outside of the original scope. If I had been an Opower salesperson, I would have pushed for us to say yes to every single request in the RFP to maximize the chances of winning a deal, and that’s exactly what the salespeople at Opower did.
Of course, in my role running product management, I wanted to say no to every feature request because saying yes meant further pushing out roadmap priorities. It was a stalemate, and while everyone appreciated that we were on the same team, it created an antagonistic relationship and a zero-sum game between sales and product. Something had to be done.
Dan Yates, co-founder and CEO of Opower, called the VP of Sales and me into his office to work it out. We asked ourselves the question, “Forgetting about the specific feature requests and roadmap priorities on the table today, what percentage of our development capacity is appropriate for saying yes to win deals and what percentage should be reserved for true product development?” It was a simple question, and to my amazement, all three of us agreed immediately: given the realities of the market we were selling into, about 15 to 20 percent should be earmarked for client commitments and the other 80 to 85 percent should be reserved for the roadmap. All we needed to do then was come up with a process for prioritizing the right work while holding ourselves accountable for matching the top-down allocation we had just set.
And so the tokens system was born. As long as sales could operate within their capacity allocation, I didn’t feel strongly about what we actually prioritized as long as it resulted in us hitting our sales targets. Sales was in the best position to determine which items were worth committing to and which could be ignored. It worked much like a paid time off plan in which for every few weeks an employee works, they earn days that they can take for vacation. As long as you remain within your earned vacation time, the company has little say in when or where you go. In the tokens system, for every 85 developer-days of product roadmap work, we would add 15 developer-days of capacity, or “tokens,” to a budget that sales could use as they deemed necessary. (I did have veto rights for requests that would result in scalability issues or overwhelming product complexity, but I rarely had to use that power.)
This process was controversial particularly within the engineering team, who felt product management should never defer to other teams. It was controversial enough, in fact, that it has become a classic case study taught at Harvard Business School. Regardless of how people felt about it, the results spoke for themselves:
- A junior salesperson working on a small deal couldn’t come to the product team directly, banging their fist on the table about a pile of feature requests. They had to instead go to the VP of Sales, who would shrug the request off immediately, noting that unless the deal size were larger, it wouldn’t be worth using up their limited tokens. Eighty percent of the one-off requests that used to come to product management vanished overnight.
- When the estimate for a truly important feature request came back higher than the salesperson expected, rather than try to force it anyway, they asked us whether we could work with them (and when possible, the client) on an 80/20 solution that would solve the utility’s need but at a fraction of the token expense. This is exactly the kind of constructive discussion we had always wanted.
- If several different clients were asking for additional product features that were roughly the same, sales leadership would ask whether they needed to spend tokens multiple times. I would respond by explaining that they didn’t need to spend them at all. Enhancing the product to satisfy the evolving needs of the market is exactly what we intended to do with the remaining 85 percent of the roadmap anyway. This was precisely the type of market insight we were looking for from our client-facing teams.
