Leading Product Edition 2
Leading Product Edition 2
Hi | Interview with a User | Cone of {Un}Certainty | Working the Farm | Portfolio Innovation with ROR | What is iPaaS? | Contemplation | Sign Off = 9.5 minutes
🎺 Welcome back!
Here we are, in March. Whenever I reflect on the passage of time (is it speeding up?) I think back to this post from the beginning of last year. It’s made the rounds, but is such a great depiction of our perceived and actual place in time relative to events.
OK, on to product.
Last edition, we looked at EMR technology and its limitations. There are also good things happening in this space, including efforts to link disparate sources of medical information through secure APIs. Protocols are powerful. Connecting Ontario is one of many examples.
For Edition 2️⃣, we’ll look at how the cone of feature / roadmap clarity helps Product People express certainty to stakeholders (and ask for resources the right way). Then I’ll share some content found online and in scholarship, our usual segments. Lastly, a quick write-up about iPaaS before the close. But first, a quick user interview story.
🏠 A User Interview
Recently, I had the opportunity to participate in a user interview — and I was the user! The product team at Jiffy reached out to schedule a call and I was happy to help. Jiffy is an online platform that connects homeowners with qualified home service providers, like electricians, in real time, based on proximity and availability. It’s a service I’ve found extremely useful, and have noticed the incremental improvements that accompany each release.
The Jiffy team has thought a lot about how to earn users’ confidence in the services rendered by professionals in their network, and vice versa. The spaces we call home are near and dear, and Jiffy’s platform injects certainty for their users (both homeowners and pros) where it was previously lacking. Being interviewed as a user is just one way to get better at conducting user interviews.
🍦 The Cone of Roadmap Clarity
As promised, I wanted to write about The Cone of Roadmap Clarity, which is a riff on Steve McConnell’s Cone of Uncertainty, as applied to software development. This Cone is a bit different, less about padding time and more about rallying around what a product will be.
The Roadmap Review
You’ve just been asked by a VP, “what will you ship in six months?” That kind of question can put you, a PM, back on your heels. Six months?, you say to yourself. Next month is a little hazy, how can I begin to describe next year. Wait, can’t YOU tell me? 😰 The VP is waiting for an answer, so you break out the cone of roadmap clarity.
Last year, Jon authored a great thread about product certainty - and the importance of uncertainty - on Twitter. It starts with this premise…🔻
… and concludes with 🔻
It’s a provocative question for product managers to ask. Certainty is kind of… cultish. I jumped on the thread to offer a take:
I've used a cone of options to show range of possible futures. Certainty is attainable for a sprint but less so for a quarter. The cone grows *smaller* to show that uncertainty increases with time. The point* of the cone indicates things of greatest priority. Graphic soon.
*I meant to say “middle” ➖
Well, graphic now…
To justify resources committed over the long term, it’s helpful to demonstrate what can be delivered into the future (two quarters +) and what might deliberately fall outside of your team’s ability to deliver. Yes, this means measuring and having a sense of workload that developers can complete. It also means having a really crisp prioritized feature list and groomed backlog. This framework should let a PM say with confidence “We won’t be working on x because… <resourcing> <priority> <perceived customer value> <etc>.”
As the cone moves along with time, you can start to adjust the level of certainty ascribed to upcoming features, as they come “into focus”. At the same time, you can protect uncertainty, as Jon challenges product teams to think about. More than any approach, it’s the firm’s culture that enables this kind of thinking. Portfolio Managers should be able to tell their PMs “It’s ok not to be sure about these things in six months, because as a company we’re not sure about hiring, budget, etc. However, you should be able to tell us (almost) exactly what you’ll ship this month.”
How might you use this? 🔲 Get it on the (virtual) whiteboard! This is a graphical depiction and, like any graphical tool, an abstraction of a lot of complex things (including human behaviour and performance). A sketch or online diagram can go a long way to bringing the concept to life.Focal Point, Wildards, and Big Bets
The Priority Focal Point shown in the graphic cuts through those features and things that must be delivered; failing to do so would have a detrimental impact on your product and ability to deliver value to customers. The features out at the edges of the cone have lesser priority, but there’s capacity to deliver them.
Over time, wildcards - features with the potential to add value but lack the data to support their build at inception - will start to come into focus and can cross the threshold to be delivered. You could work on so-called wildcards while they’re still blurry, but that’s taking a risk.
How do we treat Big Bets? Big Bets are feature sets, perhaps an entirely new functionality (“we’re going mobile”), that represent a lot of work, and a paradigm shift for the product. All things being equal, they might remain outside of the cone (i.e. what you plan to deliver) until funding is unlocked to marshal the necessary resources. But, they should still be tracked and identified as opportunities down the road, if only to maintain visibility and keep the team oriented to the possibility they might one day ship.
These aren’t the only categories out there, but they can be used to frame resource requests accordingly, in terms of what you’re looking to achieve and get on the roadmap, while being explicit about what won’t (at least for ‘now’).
In Closing
Knowing what a team can’t/won’t/shouldn’t ship is as important as being certain about what they can/will/should; elevate uncertainty to the same level of certainty and your roadmap, and the team it guides, will benefit. It can be tempting to approach the backlog with “every feature will make it, it’s only a matter of time!” But that’s not pragmatic. Along with other tools, the Cone of Roadmap Clarity can help (I hope).
Another thought: Certainty and uncertainty are elusive, and perhaps limiting. Rather than strive for placing features in one of those two buckets, PMs might seek clarity and alignment across the firm about the features that will be delivered, the ones that could be if the right conditions exist, and the ones that won’t.
Have you used this approach? Is it useful?
Further listening and reading…
🔉 Jon hosts the Developer Tea podcast. Great vibes.
⬇️ For more about certainty, keep scrolling.
🐄 #FarmLife
Found online
On Friday the CEO of SomaDetect (and my sister), Bethany, did a live interview with Sarah Barker for Ireland’s Dogpatch Labs.
💎 The exchange features a ton of gems that Product People will find relevant: customer discovery, product-market/context-fit, pricing strategies, letters of intent, and how to accept and filter advice. Worth watching in full, especially for those in #AgTech.
Here’s a clip. And another. OK, and one more.
🎰 Real Options Reasoning (ROR)
Found in scholarship - “How do strategic and cultural contextual structures moderate ROR’s influence on portfolio innovativeness and, eventually, on portfolio success?”
You needed another TLA
in your life. Picture this: You’re in a large company, with multiple, related products that neatly fit within a portfolio that differentiates your company in the marketplace. To remain competitive, what do you ship next? There’s a ton of pressure from the leadership to ✌️be innovative✌️. Do you take big, bold bets? But there’s too much uncertainty! (There’s that word, again). Real Options Reasoning is your friend.Kaufmann, Kock, and Gemünden explore how portfolio managers can drive innovation by applying ROR to the analysis of potential opportunities, in an effort to answer the questions 🔺. The study’s findings support a positive correlation between the ROR approach and portfolio success, with other important factors operating in the background (i.e. entrepreneurial orientation, innovation climate).
Thriving in the Fuzzy Front End
ROR is a way to confront uncertainty in product success by (1) allocating capital over time (think funding rounds!); (2) abandoning live projects as a completely acceptable decision; and, (3) re-allocating capital during planned reviews “from unfavourable to more promising project options.” ROR is a gut check, and injects data-driven decisions and learning into the chartering process.
🙊 How Darwinian!
Decision-makers have a finite amount of attention to devote to assessments of a product’s viability to decide what makes it into the portfolio. ROR is a behavioural approach used to “place only tentative, structured bets, and successively strive toward reducing various options’ uncertainty” about a project’s success. Over time, uncertainty is removed as data is collected and a given project can appear to have more (or less) potential. Capital is allocated accordingly, with the decision to terminate normalized as a perfectly acceptable outcome. (Projects develop momentum of their own, and it can be a difficult decision to hit the ⏸️ button.) The application of ROR principles enables teams to overcome the emotional biases associated with traditional “static resource allocation” regimes.
We’ve made it this far. Can’t turn back now!
Remember when fail fast was a good thing? It’s still important to fail at the right things.
Innovation Portfolio Success
In particular, the authors investigate the relationship between ROR and Innovation Portfolio Success. I wanted to share a graphical depiction of IPS as it’s a helpful framework to guide decision-making in any firm. Put it on the office fridge (eventually).
🌈 Better Know a -Product Skill- Tech
(That’s a strikethrough) 🙄
Normally I explore a skill or approach (e.g. JTBD) but I was intrigued by a recent PM role advert that mentions iPaaS. I’m familiar with Platform-as-a-Service, and I knew you could put the letter i in front of words, but iPaaS was a new one to me! Clearly I’d missed something, since iPaaS has been a thing for at least a decade; Gartner had a reference model in 2011! Let’s take a look.
Go forth and integrate!
Integration Platform-as-a-Service, or iPaaS, lets companies connect applications, data sources/providers, and devices across the different types of hosting environments (i.e. cloud, on premise, etc.). So it’s considered a flavour of PaaS, to be reductionist.
For firms shifting from a service-oriented architecture (SOA) to event-driven architecture (EDA) that includes cloud-native applications, iPaaS solutions include the adapters, connectors, and rules** needed to power high-volume, real-time transactions and events across diverse systems hosted anywhere.
**I suspect the need to customize these is still a heavy lift.
According to Solace, iPaaS paired with an event broker benefits large companies with a legacy footprint that isn’t going away; implementing both enables companies deploy “new applications to interoperate seamlessly with legacy systems so you can migrate workloads in a step-by-step, flow-by-flow manner instead of trying to execute an impractical ‘lift and shift’.”
Nice value prop.
Further Reading
iPaaS – perfect-fitted solution for large enterprise systems? By Robert Witkowski, Lead Software Engineer, ASC
🤔 Contemplation
How do we express confidence in uncertainty?
Until Next Time
Thanks for signing up to read Leading Product! Feedback, discoveries, counter-arguments, and corrections are always welcome!
Three Letter Acronym. Very sorry.