Navigating Uncertainty in Ventures
Embracing the learning mindset as a venture designer.
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer.
Venture building is about learning, but how do you know what you need to learn to begin with?
I mentioned in my first article that venture designers spend a lot of time doing non-design activities. Building tools to learn what nobody knows is one of them.
In this article, I will not only share mindsets and tools I use, but also a detailed approach to building the most important learning tool — a product’s OKR system. This article will help you get ready to be a venture designer, or become a better one.
Venture designers’ reality
“Nobody knows, and that’s great!”
Being successful in the venture world is about making bricks without straw. If you are a product designer or a UX designer, I bet you are familiar with the “requirement gathering” activity that usually happens at the beginning of any UX design process.
When I was a young designer, I used to follow that process and ask for what I need when I joined a new project. Four years passed, as a mature venture designer, I learned to set my expectations low.
This is what I would expect now when I ask the following questions:
Is there a product vision?
- Maybe, but there is nothing solid at this point. It can be changed anytime. Is there a product?
- Yes, and it can be anything between a mature, commercialized product and a naked concept.What’s not working?
- There is something wrong but nobody knows what it is. “I am sure it can be improved.”
Not having good answers to these questions doesn’t mean that you are on a bad team, or the project is not going well. Quite the opposite. These are strong signals that the team needs you. To navigate uncertainty, a venture designer needs to be able to handle missing information. I will show the mindsets and tools I use so that you can get ready for even the toughest situation.
A venture designer is always ready to handle missing information.
What is missing?
“Sometimes the better question is: What do we have?”
If a team doesn’t have a product vision or a working product, we have nothing to start with, right?
Wrong.
One thing you know for sure exists is the project itself. There is always a reason why a project is initiated and funded. In other words, there is a willingness to learn, that’s what you need to get the snowball rolling.
“It’s not what you need, but what you need right now.”
The snowball can’t roll in the right direction without a kick. That kick is the system that bridges the project intents and the desired outcomes. We call it the OKR system.
An OKR system is the missing tool that you cannot start learning without.
Product strategy and OKRs together to form the northern-star, the performance tracking mechanism, and the health report of a product. In many cases, an OKR system informs the product’s business model. If product strategy sets the destination, the OKR system is the vehicle to get there.
“If it’s so important, why don’t we have it?”
An OKR system is rarely prioritized in the product development process for many reasons:
- It’s not generally agreed who should be doing this and when, leaving no one working on it. This is very common, especially in large organizations.
- When a product is being developed, anything and everything can change in the next moment. Setting up an evaluation system before a working product is built seems like a waste of time.
- Nobody knows how to track product performance without tying it to a viable business model, which becomes an excuse for not defining OKRs.
All the above can be easily solved if we know who should be building the OKR system, when, what exactly needs to be built, how to build it, and how to build a good one. But why should you care?
“If you work on a product and you don’t know the OKRs, you can’t know what impact you are making regardless of your role.”
You can’t improve what you can’t measure. A product’s performance is measured by its OKR system. For the simple sake of knowing what your job-to-be-done is and how you can improve the product, you need to know the OKRs.
Who should be building it?
“You.”
If you need a tool to do your job, as a venture designer, you either go get it from somewhere or create it. This applies everything you need in the venture-building journey.
I am always excited when I know an OKR system doesn’t exist. Because then I am “authorized” to build one. The more I think about the product, the more I know about it, the more likely I am to do a great job because I literally “define my success”. So I will not hesitate to take this responsibility, and you shouldn’t either.
So next time when you notice the need to build an OKR system, congratulations! Here comes your opportunity to thrive.
When?
“As early as possible, as soon as you realize it.”
Myth: OKRs should be defined based on the business model.
Some people believe a business model is a prerequisite of an OKR system, so they tend to use the absence of a viable business model as an excuse for not building OKRs. This is not true at all. I proved it in the Clubhouse case study I published recently. As long as you understand the product idea, you can build an OKR system from the ground up.
The truth is, without an OKR system, there is no way for the product team to make an educated guess on what could work as a business model. After all, you don’t build business models by throwing dices.
The moment you realize the OKR system is not there is the best time to build one.
What, and how?
“Product life cycle determines the product’s strategic objective at different stages. The strategic objective drives the interaction model. The interaction model shapes the OKR system. The OKR system then informs the business model.”
A minimum viable OKR system is made up of a strategic objective, a primary OKR, and a set of secondary OKRs. OKRs are established based on the core interactions in the product’s interaction model.
Product interaction model
A product’s interaction model is made up of core interactions at different stages in the product life cycle. Each stage should have at least one clear strategic objective. We can identify, or design, core interactions by examining the strategic objective and amplifying the value created.
Core interactions at different stages
Introduction and growth
At the introduction stage and the growth stage, core interactions are what bring users to the product and deliver the most value.
Google Drive’s core interactions will be “uploading files” and “using the cloud space”. For Clubhouse, these can be “joining an existing conversation” or“inviting Clubhouse connections to a chatroom” (Read more here).
Maturity
At the maturity stage, the core interactions are what prevent users from leaving the product. These interactions should have two characteristics:
- Increasing marginal value (the more it’s performed, the more value is delivered)
- Increasing marginal cost of leaving (the more it’s performed, the more data is locked in the product, the higher is the switching cost).
For Google Drive, “deleting offline files” is a core interaction that happens outside of the app but adds value to the app. “Subscribing to cloud space” is another example that increases the marginal cost of leaving. Anti-interactions
I mentioned a concept called “Anti-interaction” in this article. Anti-interactions allow the transfer of value created within the product to somewhere else. In simple words, anti-interaction takes users away from the product.
One anti-interaction for Google Drive is “using airdrop to transfer documents” because it takes away the need to save a document online. For Clubhouse, “adding Clubhouse connections on other group-based platforms such as WeChat” will be an anti-interaction.
Decline
At the decline stage, the core interactions are what attract new and valuable users. Attracting users that will add value to the product is the key. Growing the wrong type of users can accelerate the declining speed.
For Google Drive, onboarding enterprise users should be a strategic objective at this stage because enterprise users are less likely to leave the product compared to individual users. A core interaction can be “sharing documents within the enterprise network.”How to design good OKRs?
“A product isn’t born with OKRs. You design them.”
Designing good OKRs is a topic that has been exhausted by product experts. I want to share what I value the most from a venture designer’s perspective. There are 5 considerations when I evaluate the “usability” of an OKR. It needs to be intuitive, generic, independent of business model, time-sensitive and has a strategic-OKR fit.
Intuitive
Can everyone interpret an OKR without diving into the calculation? If someone cannot tell whether a decline in an OKR is good or bad, or if it’s unintuitive (e.g. a number going up indicates something bad), then it needs to be redesigned.
Generic
Just like a product, OKRs evolve over time. Early-stage OKRs should be persona-agnostic. For example, Google Drive’s early-stage OKRs should work for all types of users including file uploaders and file receivers. After a business model is established, the team can fine-tune the OKRs based on user roles.
Independent of business model
The theme of this article is that OKRs need to be in place regardless of whether the product is commercialized. A business model is not necessary to keep a product going for the short term. Successful ventures use OKRs to make informed business model decisions.
Time-sensitive
An evolving product will naturally allow more interactions over time. A good OKR system keeps track of the fundamental and the new interactions. If the same OKRs are used over more than 6 months, the team should reflect on whether they are learning enough from these OKRs.
Strategy-OKR fit
However good the OKRs are, if they aren’t aligned with the product strategy, it’s meaningless to the business. You can evaluate if an OKR system has Strategy-OKR fit by mapping out a strategy-OKR map like this:
Bonus: How are OKRs and business model connected?
“Whichever gets developed first should support the other.”
As you see, a product’s interaction model can be designed independently of its business model, this is also how it’s usually done in practice. However, the two teams working on them should work very closely together as whichever gets developed first should support the other.
“Use OKRs to informed business model development.”
If the OKR system is designed right, the strength and weakness of the product will surface through the OKRs. You want to take advantage of the strength of the product and build a business model around that.
For example, if Clubhouse finds in its OKRs that users are more engaged in conversations happened within groups that are far beyond their immediate network, it can charge people an entrance fee to enter rooms beyond 3 degrees of connection of their immediate network. In this case, the business model is about helping people connect through serendipity. If you look close the OKRs will tell you where the value is created for the users.
The biggest challenge for Clubhouse, though, is to consistently deliver value to the users through chatrooms. Additionally, relying on a small group of quality users to maintain the quality of the network is not sustainable in the long term. If there is no control/incentives for users to provide good content, the quality of the conversations will decline to the point that no value is generated or delivered.
To learn more about this topic, please read the Clubhouse case study.
Last note…
If an interaction model is developed first, the team should start business model development as the product hits its OKR goals consistently. A product needs a viable business model to fuel its core interactions before the growth plateaus.
About
If you are new to this publication, Welcome! I am a venture designer and a product strategist, currently working at PwC Labs. I help venture teams develop and commercialize what start as experimental concepts
.This publication is dedicated to venture design. I will share all things I learned about building ventures and venture products within an enterprise including tools, frameworks, and activities.
Venture design is an emergent and exciting domain. Please subscribe to this publication if this topic attracts you.
You can also buy me a coffee now
Your generosity and curiosity will keep me going. Click the image below to go to my coffee guesthouse.
Thank you for supporting me. See you in my next post. 👋
