Strategy is not…

There are many words that are bandied about lightly in professional circles, that one can make a career out of pointing out their absurdity. However, few words are super important, and yet so poorly understood (and thus, used trivially) as “Strategy”.

This post is a short cheat sheet to distinguish good strategy, from bad strategy, based on efficient recollection of one of my favorite books – Good Strategy, Bad Strategy by Richard Rumelt.

• Strategy is not a set of desired results coupled with things we like
• Strategy is not what you hope your performance would be
• Strategy is not a set of goals that ignores the basic problem
• Strategy is not a loose set of tactics for every day problems

Strategy is…

• Strategy is specific for problems at hand
• Strategy addresses a high stakes challenge or opportunity
• Strategy is a set of coherent actions and policies
• Strategy leverages unique strengths
• Strategy enables elimination of actions that have low leverage

What is the kernel of a good strategy?

Diagnosis

• What is the problem?
• What is the evidence of the problem?
• Who’s problem is it, and why is it a problem?
• What is the trend with all externalities?

Guiding policy

• What patterns can we discern?
• Can we anticipate actions of others?
• Use patterns to go look for solutions of a certain type

Tactics

• Specific actions based on guiding policy which is based in the diagnosis

If you’ve made it this far, you must spend another hour watching this excellent talk by Rumelt.

Demystifying design for techies

For much of my professional career, I’ve felt that I’ve been fighting the notion that techies don’t understand design. That design is this fleeting and abstract concept that only “creative” types understand. This almost suggests that engineers are not creative, which itself is a silly notion but I digress. Let’s talk about design.

What is design?

Don Norman, in The Design of Everyday Things, quotes a designer as saying that design is the successive application of constraints till one ends up with a unique product.

Design is the successive application of constraints till one ends up with a unique product.

Having spent some years of my life studying design optimization, from a mathematical perspective, a design problem is considered well defined if it has the following information

1. Objectives (min / max)
2. Design variables (where)
3. Constraints (such that)
4. Analyzer(s)

It doesn’t take much to notice that the mathematical definition of a design problem is a more rigorous representation of the first statement. Additionally, gradient based as well as stochastic optimization methods require that solving a non-trivial design problem is iterative.

How might one apply this to building new products?

Lets establish some parallels.

Objectives are statements of value or use cases that will be realized when the product (or feature set is built).

Design variables when designing a new product are all the decisions you can make about the product, from interaction design, to type face, to speed of analysis.

Constraints are different criteria that the design must adhere to. This ranges from performance criteria (how quickly must the page load) to how many clicks the user should derive value in. Constraints can be fuzzy, pre-determined, or determined while solving the problem (often called “design by shopping”)

Analyzers in a design problem tells us how well the design is doing. This can be users, or some representation of the world that we are trying to improve. This why usability testing or experimentation is so critical to design. One simply can’t design absent of analyzers. I hope techies begin to see design for what it is, a well defined problem, and start to think of creative ways of putting it front and center when they build products. It’s time techies reclaim design, and start participating actively in the design process.

Let’s not design things to be difficult to use

Recently, I read this wired article on why we should design somethings to be “difficult” to use. After reading it, I realized that the author uses all the right reasons but comes up with the wrong conclusion for all of them.

tl;dr: No, don’t make things difficult to use. Understand your user, and make things that work for them, and then make them easy to learn and use.

Pleasures of mastery

The author cites Flow but ignores that Flow emphasizes incremental difficulty to allow users to learn, explore, and become better with more practice. Contrary to the take away of this article, flow emphasizes matching difficulty to skill, and arguably makes a case for making things less difficult.

Difficulty makes things exclusive

The author cites an example of a product failing because it made things so easy that the users felt threatened.

Here the challenge is not that the software was easy to use, it was that it failed to take the users on a journey, and was perhaps devoid of feedback they needed to trust the software. E.g. Airbus when it launched the first fly by wire jet, created a joystick which controlled the airplane electronically. Pilots were used to hydraulic controls that gave them feedback when they steered the plane. The pilots militated against because the joystick made things “too easy” and gave them no feedback.

As product managers, we shouldn’t conflate adoption problems with ease of use. Great products take entrenched users on a journey where they discover their own super powers as they spend more time with the product. Great products should threaten their users no more than an Iron Man suit threatens a skilled soldier.

Danger may be safer

This is an interesting point as it positions those who build software as paternalists, who understand what’s best for the user (as opposed to what’s the best way to solve a user’s problem). For some products, this makes sense (e.g., a modern jet will override what the pilot is trying to do if it is detrimental to the plane). Again, good software decides the best way to help a user make a good decision is by giving them feedback on bad decisions, not by making things difficult. This problem is solved by approaches of soft paternalism, e.g. choice architecture.

Expert Mode & The Pro Am phenomena

This is worrisome misrepresentation. The driving phenomena here is that the user desires more capabilities, not necessarily more difficulty. Ease of use is a subjective concept, where the subject is the user. If a user needs more powerful features in a product, or greater control, these features should be done in a manner that is easy for such a user. If such a product turns out to be difficult for a novice, so be it.

Are you making it easy to do something badly?

I think the case the author is trying to make is not one for difficulty, but for products that *work* . If a product doesn’t work, making it easy will certainly frustrate users (e.g. word correction on iOS is extremely infuriating more often than not, because it doesn’t work and is super easy)

Let the objective not be to make things difficult, but if things are difficult, try to understand what the user is trying to do, and how the product enables the user. Ease is a subjective construct, and is defined by the user and the user’s needs. Great designers understand this, and can take users on a journey.

“By the time I grow up, won’t everything be fixed?”

When I was in 5th grade, I remember watching my dad repair a barometer at home. He had spilled mercury on the floor from a barometer. He was picking it up carefully, and refilling the barometer.I remember asking him what he is doing, and he went to great length to explain how a barometer measures pressure, and then what pressure itself is.

On other occasions, we talked about airplanes, and he talked about how shape of nozzles and diffusers is an area of important research, as is the shape of wings itself. While the details might be off, many of our conversations when I was a young boy followed this arc. For background, my dad ‘s a professor of engineering at IIT Delhi, and an old fashioned researcher – you know, the kind that built stuff to study phenomena as opposed to simulate it.

To the 10 year old in me, most of it made little sense, but I distinctly remember asking him what one needs to do to get a PhD. He told me you have to build something new to get a PhD, or explain something that no one yet understands. I quickly responded “Hasn’t everything been understood already? By the time I grow up, all problems would have been solved.” After all, a lot of the conversations I had with my dad were about how mankind has made all these wonderful things. I was disturbed enough that I remember that moment till this day. I also remember him laughing and telling me that there is a lot to be done.

I was thinking about this today, especially with my generally impatient glass half empty temperament. I get excited and infuriated by all the things I think are broken. Everything I see around me needs fixing, and I feel powerless, yet empowered. There is so much to fix, and so little time. Thanks for all the random chats I had with my dad when I was 10 years old, I now have an insufferable desire to make things better.

Technology as an antidote for corruption and lack of safety

tl;dr – Services we value for their convenience in this country will likely be exponentially more valuable in a country like India where they provide a corruption free and safe environment – the foundation of Maslow’s hierarchy of needs

One of core value propositions for services like Uber, Doordash, Instacart is that  these companies increase convenience for consumers, which results in a higher quality of life. Further, they also provide the benefit of resource sharing which implies that if like me, you live in a city, you won’t need to own a car.

I think intermediation or disintermediation by tech companies has potentially much greater impact of improving quality of life in developing countries where they can prevent corruption as well as increase the safety of consumers.

To study this in more concretely, lets examine some use cases in India.

1. Booking train travel – For what seemed like ages, you had to go to an office and stand in line for hours to book tickets to travel by rail in India. It wasn’t that the lines were long, but in order to buy your ticket, more often than not you’d have to bribe the ticket agent. As soon as online booking was introduced, not only did booking travel become easier (no lines), bribery completely disappeared
2. Hailing taxis – India’s capital Delhi is notorious for being unsafe for women, as well as unscrupulous taxi drivers who almost always take the longer route to get you from point A to B. Now with services like Meru Cab, and Uber, there are multiple safety mechanisms in place which provide women a safe means to travel, and there is slim chance of the rider being swindled by a taxi driver

Let’s look at a few more illustrative use cases that haven’t been solved.

1. Reporting grievances – It is nearly impossible for the government to learn about day to day problems that citizens face in India. I’m referring to fairly basic issues like broken sewage, potholed streets, non functional street lamps, garbage in the streets, etc. While the government might have good intent to solve such issues, bureaucracy creates barriers to moving this information. A simple mobile phone app which allows citizens to report common issues could not only create transparency, it would also allow resources to be diverted in a timely manner to the most important problems. There is a possibility that only those with access to phones would be able to report this, but cell phones are more ubiquitous than toilets in India.
2. Permitting -Police officers harass vendors regularly in India when they setup their stalls. Officers claims that vendors don’t have permits to set up stalls in that location, even when they do. Officers use opaque loopholes to extort vendors. As a result, vendors have to pay bribes even though they run legitimate businesses. With the advent of low cost location sensors, there is no reason why a location aware electronic permit can’t be issued to vendors. If the light is green (based on their location), they have a right to be there. This will ensure police officers can’t use opaque rules to extort small business owners.

These might not be the best use cases, and I’m sure entrepreneurs living in India can think of a whole lot more.

The broader point is that services we value for their convenience in this country will likely be exponentially more valuable in a country like India where they provide a corruption free and safe environment – the foundation of Maslow’s hierarchy of needs

On SaaS metrics

To those who know me, know that I’m a voracious consumer of all things SaaS, especially on the business side of SaaS. Recently, I read this excellent presentation on The Social + Capital Partnership’s take of what they look for in Enterprise SaaS investments, and some questions come to mind.

1. The quick ratio is handy, but it merges new sales & upsell. The underlying phenomena that drives these two measures are very different. The former is driven by promise of the the product, and the latter by the product. Wonder what the motivation is behind combining the two, as it seems to take away more by obfuscation than it adds by the way of simplification.
2. Lifecycle of the company (years since it was founded) probably matters quite a bit to how you compare / evaluate the ratios. Without knowing where a company is in its lifecycle, comparing ratios isn’t terribly helpful.
3. No mention of logo churn. With SaaS, new sales effort goes into landing into accounts, and therefore, losing accounts is painful, relative to losing revenue to contraction. Broadly, logo churn seems to be missing from how investors look at SaaS. Wonder why
4. While revenue is the rubber-meets-the-road indicator, I feel that user engagement (often a business specific metric as opposed to the canned DAU or MAU) is always a better leading indicator as its closer to the value prop of a product. Revenue growth (new or expansion) can mask underlying issues. Interestingly, the most successful SaaS companies and their investors (think Slack) discuss user engagement when it is off the charts, but it isn’t pervasive to most discussions on SaaS. Wonder if its because the right metric for engagement is hard to discover, & compare.