Category: Product Management

Categories
Product Management Startups

Desire-friction mismatch

Today

This reminded me of something: for ten years now, I have dealt with or advised founders about desire-friction mismatch.

Founders often assume that because they have built a particular product that a certain defined market segment desires – ie because they have achieved product market fit, that their numbers should now take off.

It doesn’t always.

PMF is an important milestone. But achieving it doesn’t tell a founder how motivated the average person in their market segment is. It doesn’t tell them how their promise tips the stakes for average would-be customers.

At a certain level of friction, customers’ desire to start using your product won’t be enough. They’ll sigh and move on.

At this point, a founder needs to engage their product person. To take whatever minimum viable product that got them to product-market-fit and iron the wrinkles out of the customers experience. These wrinkles exist as a result of compromises made – rightly – to speed up the initial go-to-market.

But now the founder needs to invest in the product so that it’s simple to understand and easy to get started with for the larger-than-earlier numbers of customers to come.

Unfortunately, it’s at this very point that a founder’s attention and investment turns from product (and tech) to sales and marketing in an attempt to acquire customers at a larger scale than during the PMF phase. To now look for sustainable, efficient acquisition/distribution channels.

What can happen – and too often does – is that a startup spends more (money, time, attention, emotion) in acquiring lots of new leads and sending them down a signup flow where the friction outweighs their desire to get through it.

When numbers don’t ramp up as quickly as expected, the founder is now unsure about the product-market-fit itself. They think about what they got wrong. Maybe they revisit it. Maybe they have the product people make cosmetic changes to the product trying to communicate the value proposition even more loudly (too often by adding more text/visual clutter).

In this case the problem isn’t that customers don’t get the value proposition. They do – the team’s now past the PMF milestone. But they don’t have the motivation to deal with the friction that the still-early product presents – not every product is as important to people’s lives as play-to-earn games like Axie are to people in the Philippines.

Being able to diagnose if it’s lack of PMF or desire-friction mismatch is often what makes the difference between an excellent startup’s post-PMF journey taking off, and sputtering.

Categories
Product Management Startups

Why don’t founders value the initial go-to-market?

I was recently asked

I can’t seem to understand why GTM (go-to-market) isn’t something that founders prioritise – is it cognitive friction? Is it a blind spot?

From my experience operating and advising early stage startups, here’s what I think is the answer:

I think it’s that in the early days of any company, in the pre-product-market-fit phase, the product and go-to-market are intimately connected. Unless you have a product with a captive market or captive IP (both rare), you need to develop and market the product in tandem. The marketing (or sales) head and the product head need to collaborate as peers. In fact, as one.

This doesn’t sit well with most founders. They usually have a clear idea of the product they want to bring to market. It’s why they set up the company in the first place. For many, it’s a chip on their shoulder, for instance they are now creating something they were not allowed to in a previous job. Consequently there’s a clear build phase where, as someone said about Steve Jobs, the only market research is looking into the mirror every day.

In turn, this means that by the time the product is ready to be taken to market, the founder is invested not just in the idea, but in its initial manifestation. The person in charge of go to market is given a fait accompli and told to sell it. The founder is confident it’ll sell because in their minds they’ve built the perfect version one.

If the startup is lucky, this approach’ll find traction. Usually, it doesn’t.

Finally, making things worse, because how invested the founder is in the product by now, they expect it to sell, quickly. And so they expect the try-learn-improve iteration phase to be dramatically shorter than it should be. That leads to a phase of short term, tactical fixes that usually doesn’t result in cracking go-to-market channels and positioning – or any learning at all.

Categories
Product Management Products and Design Startups The Dark Forest of the Internet Wellness when Always-On

Failure to empathise

On a new feature in Slack via which anyone on Slack can message any other Slack user, across companies:

When Slack introduced the feature today, it hadn’t implemented any features that can help someone who gets harassed. There is no block button or built in mechanism to report the message to Slack or your company’s Slack administrator.

https://twitter.com/44/status/1374737695444901891

Slack reacted:

… “we received valuable feedback from our users about how email invitations to use the feature could potentially be used to send abusive or harassing messages. We are taking immediate steps to prevent this kind of abuse”

– Slack Says Letting Anyone Message Anyone With Few Limits Was ‘a Mistake’

This is a failure to empathise, a rather basic failure when designing products. Gmail took off in its early days in large part because it decimated spam. That is a fifteen year old lesson. Twitter’s issues with harassment and spam are an ongoing lesson.

At Slack’s scale, one should expect product managers to consider the potential for harassment. For information overload. For ambiguity. For bias.

If Slack – or any other company – consciously builds and promotes its products to be used by organisations of all sizes, across all industries, globally, they cannot also dismiss or discount these as incovenient or unnecessary.

These considerations will slow down design and development, they will make the product somewhat less agile and they will increase monetary costs.

That’s the price of making a product that widely available.

You expect that with the increase revenue from this scale, you hire the best product, design and engineering talent to build efficiently while also considering everything above.

(ends)

Categories
Life Design Product Management Startups

Authenticity

Mundane as it sounds, that’s the most powerful motivator of all, not just in startups, but in most ambitious undertakings: to be genuinely interested in what you’re building. This is what really drives billionaires, or at least the ones who become billionaires from starting companies. The company is their project.

One thing few people realize about billionaires is that all of them could have stopped sooner. They could have gotten acquired, or found someone else to run the company. Many founders do. The ones who become really rich are the ones who keep working. And what makes them keep working is not just money. What keeps them working is the same thing that keeps anyone else working when they could stop if they wanted to: that there’s nothing else they’d rather do.

That, not exploiting people, is the defining quality of people who become billionaires from starting companies. So that’s what YC looks for in founders: authenticity. 

– Paul Graham, “Billionaires Build”

This is actually harder than it sounds. Authenticity is rare. If we could assume that everyone we met was authentic, navigating personal, professional and other spheres would be a lot less stressful for most of us.

But it is also because authenticity is so rare that it is such a powerful signalling mechanism with go-to-market, customer engagement, and especially hiring. I have seen each of these first-hand.

Categories
Discovery and Curation Product Management

Understand your search; search to understand

A blogger describes their “best SEO tactic so far”

The single most successful strategy I’ve found for getting search engine traffic for a more niche site has been to pay very close attention when something is difficult to find online. This isn’t very difficult to do, since it’s easy to notice when something is frustrating. The key is to be aware and take notes.

Look at your browser history and write down the exact queries you typed…

… after you’ve learned what you were trying to learn during your frustrating search, create the very thing you were trying to find… Make your own version of the resource you finally found, but fix whatever issue made it difficult to find.

This strategy tends to be stable because it works with the search engine and doesn’t tend to get crushed by updates the way more aggressive techniques do. It leads to creating genuinely helpful resources for people to find online and Google has every incentive to return them in its results.

Content created this way tends to rank well because the entire strategy revolves around escaping competition.

This is less a tactic or a hack than the essence of SEO – literally optimising for what people are searching for. No wonder it is resilient to search algorithm updates – it’s not optimising for the algo. It goes straight to the human.

This made me think of what I learnt at some point when building direct to consumer products. When talking to your customers, pay attention to the terms they use to describe their problem or their current solution.

Often the designer or copywriter will use ‘industry’ terms on the site, in literature or within the product, because those are what the team uses to communicate with each other internally. You’ve probably noticed this yourself as a customer when you’ve called a helpline.

This is why it’s important for you, as a product manager, to handle customer support and have product-market-fit conversations regularly. Understanding words, phrases your customers use helps make your product more relatable, more human and ultimately more attractive in an environment saturated with options and alternatives.

Categories
Product Management

Solving vs building

(Also posted on Linkedin)

One thing I have tried to make sure wherever I have run direct to consumer Product is to that the goal of the product + engineering teams is solving business problems, as opposed to knocking items off a roadmap list, however efficiently.

Knocking items off a list is akin to treating the symptoms rather than the underlying problem. Typically, the business owner doesn’t see enough users or enough revenue on their top-level dashboard (the symptom), so they keep suggesting product improvements and enhancements hoping one of them will be a hit with customers.

This is instead of tackling potential underlying problems. Poor free trial conversion rates, poor repeat usage of a particular revenue generating feature, below-par referral rates from existing customers, frequent customer complaints about a common issue – these are what problems sound like.

Marty Kagan of the Silicon Valley Product Group contrasts these well in his influential blog post “Product vs. Feature Teams“:

Specifically, [product teams] are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve… [but] much more often than not, the teams are not empowered at all. 

A team that builds line item after line item from sheet after sheet is a team that quickly feels it’s on an endless assembly line – because it is: product writes a specification, design translates it visually, engineering builds it, QA tests it, marketing sells it. Next.

If you had a cross functional team that instead tackled business problems, things’d be very different: 

  • Inherent to the idea of solving a problem is making explicit assumptions, forming hypotheses, building in order to test those hypotheses – otherwise how does one know one is successful? 
  • That leads to learning – what works and what doesn’t – so the next thing the team takes on is more likely to succeed with customers, and so on. That leads to momentum – the holy grail for any product.
  • And finally, teams that are cross-functional learn collectively instead of it residing in an individual, or being lost.

Such teams are rare because of the belief that solid roadmaps are what make management dashboards look good.

There are two important caveats to this:

First: Most DTC products will go though alternating phases of build and optimise. My experience is that companies spend far too long building and too little optimising. You build when you spot – and validate – a new opportunity: expanding into adjacent market or an externality like a welcome change in regulation. You optimise to get this right. Build is when a short list of features is in order. Optimise is when you solve problems.

Second: The problem-centric approach doesn’t apply to the early stages of a new product or a startup, where the point is to create and put out in the world something tangible. But once it begins approaching product-market-fit, leadership needs to make the shift from feature to product teams.

Categories
Data Custody Product Management The Next Computer Wellness when Always-On

Feedback and motivation, app edition – Part 1

We saw yesterday that I moved my Fitbit app to the home screen. This placement of the app is solely for me to log my water intake, available as a home screen quick action:

I have ended up using this despite me creating my own iOS Shortcut. Even though my shortcut is easy to launch, offers a menu of sizes instead of having to type an amount, and stores my intake and timestamp in an open plaintext format. This was puzzling to me.

When I reflected on this, I understood that the Ftibit app gave me a view of my progress towards the day’s goal (which I had set), and compared it with previous days’. My Shortcut logged data with less friction, but I have yet to build in any feedback about the day’s total intake.

That little gap, that failure to close the loop – led me to unconsciously gravitate towards something less elegant and more time-consuming. There’s a little bit of the Hooked framework at play here:

Trigger, Action and Investment are self-explanatory in this context. The reward here is not variable in the way checking for new email and for Instagram likes is, but it’s good to know how close I am to my daily intake goal – I’ve forgotten from the last time I logged my water intake and checked.

Understanding this has helped me be aware of how much I’m influenced by such signals. I’ll be more deliberate in building these into systems I create for myself, and to watch out for such patterns in systems I interact with, beyond obvious ones like badgers and notifications.

(Part 2 – another app in my routine that incorporates feedback and motivation)

Categories
Product Management

Panel discussion on Product Management as a career – and some reflection

A couple of weeks ago, I was on a panel discussion with other IIM Kozhikode alumni on Product Management as a career. Here is the video (90 minutes, but the YouTube page description has time-links to specific topics)

Unlike the rest of the panel, I’ve never formally run Product except for a brief period in 2013-14. I’ve always played a GM role who’s also run Product. After years of imposter syndrome, I think I’ve finally come to see this as a positive: that Product’s fallen automatically to me every time even though I was _supposed_ to be operating the overall business.

Finally, almost all of my career has been either in early stage startups or in early-stage skunkworks units within midsized companies. As someone who likes deep focused work, I’ve had to consciously shift to being comfortable with uncertainty, scarce resources and speed. I find that it still causes fatigue and occasional frustration, but having accepted these constraints, I am vastly better at dealing with it now than at the beginning.

End note: when asked to name two books that early Product Managers would find helpful, I suggested

  • How The Web Was Won by Paul Andrews, a 1999 book on a few technical and Product people at Microsoft in the early to mid 90s who, unknown to each other, got an entire organization to embrace the open web. Though not about Product Management per se, it’s a remarkably inspirational book about both the building of new products and about initiative.
  • Life After Google by George Gilder, a 2018 book on new disruptive areas of technology and the world they are likely to create. Again not about Product Management, but a great guide to the areas where new products will be built in the near future.

Categories
Data Custody Privacy and Anonymity Product Management

Open-washing and Category Pollution

This week I learnt of the concept of open-washing, labelling a project ‘open’ without any actual substantial openness. Mozilla responded to India’s IT ministry’s call for feedback about its Strategy for National Open Digital Ecosystems:

…the current white paper also leaves much to be elucidated on both the need and manner of implementation of such ecosystems before a national strategy can be finalized. In addition to a distinct lack of clarity on how governance mechanisms of NODEs would operate within existing and upcoming regulatory frameworks, the paper also creates the potential for ‘open-washing’ of projects. 

because

The white paper leaves the definition of “open” vague and at the complete discretion of individual implementers. Consequently, implementers are not required to adhere to any minimum baseline of “open”. This risks empowering private parties to develop closed ecosystems that are only open in appearance while being closed in practice.

The response recommends that the ministry define 

a clear minimum baseline for “openness,” guided by internationally accepted best practices and the Indian government’s own policies. Adherence to this minimum baseline should be made a mandatory criterion for a project to be considered a NODE.

Having read this, it sounded analogous to what I call Category Pollution. 

This occurs when a company or its product runs a high-visibility awareness or distribution campaign claiming to be part of a new field, but in fact does only the bare minimum to qualify. 

People who experience the product are inevitably let down, but it also sours them on even considering other players in this new fields whose product are in fact deserving of the new label. The company’s campaign has polluted the new term, the new category itself. 

I have most recently seen this in the ‘wealth tech’ or ‘digital wealth’ space in India. Products that do little more than offer mutual funds claim to provide Wealth services. People who sign up for what they think is a new way to invest in a range of assets are disappointed and are unlikely to trust others truly different products in the space.