Things are often both far less complicated and more complicated than people seem to assume.
This is true in product:
If you’re finding yourself lost in the complexity of your product you’re probably conflating too many things together.
Tackle the simple stuff first and iterate from there.
How do you manage customer expectations as a B2B SaaS company rotating from sales and customer lead to product lead?
You have to have a clean break from the past.
Set up a cross functional meeting with their key stakeholders to explain...
We have a new product team and process in place to create world-class products for you and all our customers
We have a set of product principles that shape all our decisions. They are...
We love working with you to collect your pain-points and validate product direction (note, I did not say collect your requirements and co-design our product with you). Specifically this work must be...
Cross-functional (Involving Domain + Product experts. Not your project manager's opinions vs. our account manager's pushback)
Focused on pain-points (Not solutions)
Calibrated (We come to you with our plans 80% baked so that you can help us calibrate our best thinking against your real-world experience)
Validated by users and data (Ultimately it's all educated guesses until we test it with real users and usage data)
Here are the current UX problems we're solving for now
Here's our vision of where this might go over 12-24 months
Here is our immediate, tactical plan for the next 1-3 months
Your support team should have a standing sync meeting with Product team and other leadership. The agenda should include...
What's on fire
- Things that need to be fixed/escalated immediately
Themes and patterns
- What's generally going well
- What's generally going poorly that should result in product, docs and/or ops changes
Metrics
- How is support performing against KPIs
- How are things improving?
Product & Show and tell
- Product showing what they're working on next
- Support helping Product to refine their thinking
- Support taking on tasks to write or update support docs
The real trick is not digital transformation, but digital disruption.
Digital transformation is about building better software systems to support your current business model and processes.
Digital disruption is about beaking your business model and rebuilding it digital first and customer first.
I’ll never forget a meeting I had while head of product at the Uber Developer Platform.
It was a weekly “business review” which, for my department, included some 10-15 people. It was basically a way to hold the product leadership (me) accountable for moving the business forward. It was always intense.
This specific meeting, however, was getting particularly heated.
Some of the stakeholders were upset about my lack of urgency about improving the “the numbers” (I.e the KPIs) that we were ostensibly supposed to focus on.
After trying to explain my hypothesis that we had built the wrong product, these particular stakeholders were unrelenting.
They only wanted to talk about the KPIs.
“I don’t care about the numbers!” I finally blurted out.
The reaction was shock and awe. The room went silent.
No one could believe that I had uttered such a sacrilegious thing!
The fact is that KPIs only matter if…
1. You have product market fit.
2. You’re not facing an existential threat from outside trends and competitors
3. Your goal is to manage toward incremental change
And that’s typically only true if you’re in a mature company acting as middle management.
If you are still trying to find product/market fit, and/or you’re trying to create step-function change, you need to step back from the KPIs and ask yourself larger, more existential questions.
Questions like…
1. How do we drive new levels of disruption
2. How do we solve real problems and delight users
3. How do we significantly grow our Total Addressable Market
Don’t just be a cog in the wheel navigating toward incremental change.
Take the time to lift your gaze and look at the horizon.
When was the last time you looked past “the numbers” and asked some bigger questions?
1. You have frequent change in priority
2. You lack clearly defined (highly specific and tactical) problems you’re solving for
3. There is frequent push back and frustration from Engineering
4. Things take too long to ship
5. When things ship they are not polished or effective
6. There’s a lot of action and maybe lots of things ship but nothing seems to ladder up to meaningful new value for customers
7. Customers don’t know what your product does or how to use it successfully
8. Your product usage is not growing
9. Your margins and/or your volume of business is too low
10. You can’t handle more customers without hiring more people
11. There is indecision about priorities and next steps across the company
12. The sales team doesn’t know how to sell your product “as is”
13. Each new customer is asking for materially new features
14. It’s hard to describe and sell your product on a website and at scale
Agile is about organizing an engineering team for regular delivery of incremental improvement over time while paying close attention to market feedback.
It is not, however, a process well suited for a) developing a long term strategic roadmap or b) rebuilding a product that is relatively well understood (either through experience or intuition) for scale.
The latter requires a planning process that doesn’t fit into the “Sprint” construction.
Once you’ve got a plan (and therefore know where you’re going), you can then execute using agile.
The trick is to know how much to plan and how to break down the plan into small incremental releases without falling into a giant waterfall.
#consultingconvos
In rapidly growing teams there’s often - if you’re lucky - a proposal that inevitably gets floated when the chaos and confusion becomes too much:
It’s often referred to as “slowing down to go faster”
This principle applies to all business types and product types but it is particularly important in the context of a marketplace where you often want to do fewer, more standardized things so you can scale.
Here are some thoughts I’ve recently had on the subject - specifically for a marketplace business:
—-
I love the concept of “slowing down to go faster” when it comes to product.
I love it so much that I’d describe it more broadly and apply it across the whole company.
More broadly it’s really about..
“Structuring and standardizing everything so a company can achieve rapid growth, scale and liquidity in its marketplace”
(JFYI liquidity means the number and ease of transactions between the participants in a marketplace. This is a measure of its success and what makes it an unstoppable business model)
This requires that - across the business - the team pause for a moment on tactics to get broad consensus on principles, patterns, programs and templates so that we can
A) push responsibility and accountability out to the edges of a rapidly growing team while
B ) still ensuring that the team can act in alignment, execute in repeatable high-scale ways and make the right decisions without excessive meetings or additional ad-Hoc work
For product this means getting consensus on…
- Problems being solved (and roughly what order)
- Products being built for each problem
- Product principles
- Product taxonomy/vocabulary
- Ways the team will be organized behind each products (ideal org chart)
- Ways of working/responsibilities for each role/group in the team
- A mid-fidelity end-to-end idealized UX so that everyone understands the shape of what‘a being built
- Decomposing the idealized UX into A roadmap of Broad themes/milestones for the product (rather than prioritizing features)
- Getting 2-3 milestones of the roadmap fully spec’d out (inc high fidelity mocks) in a way that covers all the product principles
- Execute and stay ahead of the milestone curve
This process broadly applies to other operational aspects of the business such as partnerships and support. They all need to act this way so that every part of the business can scale at the same rate.
Obviously when applied to other parts of the business, some of the details of consensus change.
For example, for partnerships, replace the word product with partnership to create partnership taxonomy/levers and partnership principles. Replace the roadmap with a prioritized partner target list. Replace the idealized product design with idealized template agreements that are clear but flexible so that everyone understands the shape of the deals we want to create. This would look like this..
- A standard list of Partnership types the business needs (and roughly what order)
- Standardized Engagement Types the business will allow
- Partnership principles
- Partnership taxonomy/vocabulary
- Ways we’re organizing the team behind these partnerships
- Ways of working/responsibilities for each role
- Ideal template agreements for each partner type and engagement that is flexible and clear and communicates the shape of this kind of engagement
- A pipeline/hit list for each partner type
- Start placing each new discussion within this framework
- Execute and stay ahead of the milestone curve
The nice bonus is that standardizing something like partnerships and support reduces complexity in the product and drives a consistent user experience in marketplace. That in turn drives more liquidity.
Final note: many companies have a version of many of these things. But the devil is in the details. They need to be reviewed and taken to the next level.
Also, once they are roughly right, it’s essential that the whole team is briefed of this consensus and starts to act in accordance with it even while leaders are not in the room.
I.e. It needs to be in the water and inform all behaviorS
Great design creates real value and may change/broaden your value prop and pricing:
Before trying to figure out what your unique differentiator or pricing strategy is - first dig deeply into how you’re going to solve a real problem for a real user. Go all the way to end-to-end mid-fidelity designs.
While doing so, you will often find that your actual unique differentiator and pricing strategy radically changes.
I’ve been involved in countless projects where the team had guessed that their value was in some magic AI/ML/Tech deep in some workflow, but it actually turned out that the beautiful user experience we designed to get to the “magic moment” was it’s own kind of significant innovation.
Three lessons:
1. Solve real problems
2. Don’t put the cart before the horse.
3. Great design is a form of innovation in-and-of itself
Often when there's a problem in a user experience, product managers and other leaders will jump to better documentation or tutorials.
Instead, there is a hierarchy of UX changes that should be tried first, second, third etc. Try fixing the problem using the tools at the top of the hierarchy before resorting to techniques lower down the list...
Improve the visual metaphor
Make it easier for the user to quickly - at a glance - understand what's going on based on the patterns and pixels on the screen
Improve the word choice/copy
Make it clearer what's expected and what's about to happen by using simpler, better sentences and button labels. It's surprising how much can be achieved with a simple word change.
Coach marks
Help users orient themselves when they first visit your app or when there's a new feature available by adding callouts and highlights.
Simple animated explainers embedded in the UI
Help users see a quick glimpse of what they need to do with a simple looping animation
Video tutorials
If you're going to educate me, then at least make it entertaining!
Documentation
This should be a last resort. The documentation should always be present but it shouldn’t be relied upon to help improve a user's day-to-day experience.
As a product manager for enterprise products with large "make-or-break" customers, you have to learn the fine art of telling customers who are demanding a new feature "nope, there's no way we're doing that" while making them feel so good that they thank you for the privilege of being rejected.
Ask yourself what might be fundamentally simplified and disrupted by re-thinking your entire business model from first principles.
For example:
1. Rather than partner with your customers, you might need to be disrupting them with a direct to consumer business. E.g. Netflix didn't help Blockbuster run a rent-by-mail business. They created their own B2C company and killed Blockbuster. Sometimes a B2B business seems obvious, safe, easy - but often a B2C approach can be far, far more valuable, exciting and impactful.
2. Rather than becoming a slightly more efficient company by automating traditional processes with better software, ask yourself if there's a fundamentally better, simpler approach that might now be possible thanks to shifting cultural trends and technology. E.g. Uber was only possible because the smartphone made the $100k Taxi fit-out unnecessary. Payments, tracking, meter - even security - were now possible with a device everyone carries in their pocket. Further, people were increasingly comfortable meeting people from the internet making peer-to-peer ride share possible. The cultural and technological realities had changed. A new, massively disruptive business could emerge.
It means that…
1. All feedback, ideas and data (from all functions and sources) flows into the product management team
2. The product management team digest and triangulate the data to develop a product strategy that is socialized with the company to drive alignment
3. The product team then develops a series of incremental tactics that ladder up to the strategic goals
4. The marketing team promotes the product that’s developed to drive interest and intent
5. The product and marketing should either sell itself or go a long way to sell itself
6. The sales team nurtures small bottom up adoption into large enterprise deals
You don't want an exclusivity deal
As a startup, there are very often deals that seem great but that you actually don't want.
For example, deals that include "exclusivity".
In many cases, exclusivity is death for high-growth, generally available, customer-facing software companies. Especially so for two or three-sided marketplaces.
Exclusivity can often cripple your ability to build a broad-based distribution strategy, partner with all the companies you need to partner with, and even entirely break your long-term business model.
The first way to begin diverting discussions about exclusivity with your potential "partners" is to remind them that they don't want exclusivity.
How could that be true?
Well because, presumably, they're picking your company as a partner because of the value it offers and its current and future strength in the market.
If an exclusivity deal undermines your business model and market position, then all it does is weaken your business and diminishes the value of the partnership. No one should want that - especially not your new partner.
Be careful about the deals you sign. Particularly the ones that seem great on the surface but will come back and bite you later.
I’ve posted many times about what it takes to turn technology into product. I’ve written about how product requires standardization, polish, self-serve and 15 other things that make it useful, scalable, and delightful.
However, it’s also important to know what it takes to build a *team* that can build products.
Many inexperienced founders think it just takes a few engineers.
This is generally incorrect.
A complete, fully funded product team typically includes...
1 x product manager
1 x engineering manager
N x engineers (ideally no fewer than 2 and no more than 5 or 7)
1 x Product designer
1 x Data scientist
1 x Product Marketing Manager
Each product team should have a durable long-term mission whereby they can develop their own roadmap and momentum.
For example, they might own “Billing and Payments” or “Discovery and Search”. These missions should not be about technical architecture like “Backend” or “Mobile”.
Further, you need 1 team per product. In this case, it’s hard to define the boundaries between individual products.
As your product gets more sophisticated, each team may own more and more granular parts of the product.
For example, at the beginning a team might own the “Admin Dashboard”, but eventually that team might be broken up into many subteams (subteams are still complete teams as described above) that own individual parts of the admin dashboard.
Finally, in the beginning, and as you're building the team and business, some resources can be shared.
For example, you could have 1 PM, 1 Product Designer and/or 1 Data scientist per 2 or 3 teams. This is a way to scale the team iteratively but it is unsustainable in the long term.
If you don’t have enough people for all the products you want to build, you must cut things and focus until the team grows. Otherwise, you’ll just tread water and/or ship crappy things.
I’ve noticed It’s difficult for community minded people to understand tech startups and to raise money for them.
They tend to be very good at nurturing a group of people around a common cause, but not building a software based business with intent to transact.
Here’s a few tips…
1. Communities are cute, but they are non-transactional, amorphous and don’t scale as a business. They are, however, useful as a marketing, retention and support tactic.
Marketplaces, on the other hand, are communities built around intent and transactions. Much more commercial, purposeful and scalable
2. Tech investors invest in tech. Not Services. What is your tech to facilitate the peer-to-peer marketplace?
3. What are your unit economics?
4. How will you scale this to touch all the relevant people?
5. Who and what are you disrupting? How big is that market?
One of the hardest things to remember when building a startup is to start with the problem.
It’s so easy to be seduced by a vision you have in your head about some way the world SHOULD work.
You fall in love with the exciting opportunities that are possible if only investors and users saw the world that same way you did.
In reality investors, and users, tend to respond with more urgency and energy when you are solving an immediate and painful problem in their everyday lives.
Find a real, urgent and (economically) painful problem. Then find a pragmatic and tactical solution.
Then, and only then, do you get permission to create new value, build network effects and change the world in creative ways.
When thinking about leave for your team as a manager, it's ideal that each person is treated as an Adult.
They should be encouraged to make their own decisions about what they need to do to balance a) their needs, b) the needs of their family and c) the needs of their team.
If you're raising money it should not be a series of random meetings.
You need to be running a process. This includes...
Warm up the process with a pre-process I call "The Roadshow". Meet with your target investors ahead of time and ask them "What would you need to see to get conviction on this business when we start raising capital". Allow at least 2-3 months for this step.
Give yourself (and investors) a fixed period of time for the fundraising process (e.g. 3 months). 1 month for first meetings. 1 month for 2nd/3rd meetings and 2nd-degree meetings. 1 month to close and bring in the capital.
Share your timeline with investors as you meet them. Explain where you and they are in the process
Have your terms and materials at your fingertips
Make sure you've noted and done the things the investors suggested during your roadshow. Show them your notes and your progress on their suggestions during the pitch meeting.
Have a spreadsheet where you track everything.
I just got an email from a founder. I thought I might share it here along with my answers in case it might help others:
Her email:
1. Can a services marketplace be (financially) sustainable in under 5 years?2. Should a services marketplace be (financially) sustainable in under 5 years? Or would this stifle the whole aim of a thriving marketplace with network effects?3. Recently a services marketplace IPO-ed and they showed a loss of millions of dollars on their books and their rationale was basically 'its a land grab.'I've heard it said 'winner takes all' ie someone gaining the most market share the fastest, but how does that work in a pandemic? We still aim for an acquisition cost that is low, but it is not the fastest way to grow.My reply:
Hi [Redacted]Have you seen my “startup scale” material? It should address most of your questions at a high level: https://www.chrissaad.com/startupscaleIn short: The goal of an early-stage, high-growth tech startup is scale. Not sustainability.There are many reasons for this articulated in the deck, including:1. Software scales in ways that traditional business operations do not. This creating massive profit potential at later stages at larger volumes when revenue becomes exponential while costs remain linear.2. Tech startups operate on aggregation theory (https://www.google.com/search?q=aggregation+theory)3. As you mentioned, marketplaces are often “winner takes most” and network effects make them hard to beat once they achieve scaleSo the answers to your question are:1. Maybe they can be sustainable under 5 years but that’s not the goal2. Not if your goal is either a) build a high growth tech startup or b) not be disrupted by a high growth tech startup3. They’re correct.4. How does it work in a Pandemic? Better than without a pandemic because people are more hungry for opportunities and work.5. Cost of acquisition should not be “low”, it should be understood relative to “lifetime value”. During early growth phases, It’s ok for acquisition costs to be higher than lifetime value. That’s what capital raising is for. It’s not “unsustainable”, it’s called “investing in growth”. As long as you have a line of sight for how to drive down costs and increase revenue once you hit scale.6. Driving costs down should include operational efficiencies, improved conversion through product improvements, and organic growth through killer network effects (supercharged by deliberate product features that create them and take advantage of them)Hope this helpsChris