Chandra Janakiraman

It's a very problems focused process, and that's an important point.

The beauty of it is each of those bigger cluster, you actually know what the sub problems are within that cluster because you sort of generated it very organically.

Imagine how frustrating that is for both the reviewer and the person who's reviewing. It could be made so much better if you just engaged with your leaders before you actually build a strategy.

The goal of the design sprint is not to sort of come up with these are the features we should build. The design sprint is to generate a lot of illustrative concepts that bring the strategy to life because a picture is worth a thousand words.

The core of strategy is really picking those areas and the areas you're not going invest in.

I started noticing that there was a certain mystique and aura about product strategy. There was this perception that some people were intrinsically really good at strategy and others were not. It was almost as if there was a strategy gene you needed to be born with to be good at it.

Are the levers unique and differentiated to that particular team or company? If another team or company could build it better than this particular team or company, then it's probably not that differentiated.

It's important not to include a roadmap as part of a strategy doc, because a strategy doc is meant to be separate from the roadmap. It's meant to be a companion to your roadmap.

Life has to be about more than just solving problems. There needs to be an aspirational and cool component to strategy.

It goes back to human psychology of just something that comes from you, feels a lot more familiar and easy to accept.

Basically strategy has no business value. It's basically a document with a few words. And I think it starts accumulating value as you generate business impact and results.

When you get somebody in the room with a user, it just changes their mind, it softens them a little bit. It gets them out of their own preconceived notions.