Book review: “Radical Candor”

In my experience, as you further your career, you’re likely to lead other people in some capacity or another. Whether you’re managing people or simply interacting with them, giving and receiving feedback can often be tricky.  I believe that being able to both share and receive feedback is a true skill that only few people have truly mastered. I for one, feel that I still have a lot to learn about how to best give constructive feedback, especially since I’d rather not use the age old “sh*t sandwich” since I don’t believe in dressing up negative feedback, and most people tend to see through the sh*t sandwich anyway.

Fig. 1 – The “Sh*t Sandwich” by Lighthouse – Taken from:

This prompted me to read “Radical Candor”, a book published earlier this year by Kim Scott. The main premise of “Radical Candor” is that you don’t need to cuss or shout or act rude to be a great boss. In contrast, the book encourages leaders to create relationships based on trust with the people that you work with.

These are the main things that I learned from reading “Radical Candor”:

  1. What do bosses do? – I really like Kim Scott’s definition of a boss’ responsibility: “bosses guide a team to achieve results.” Bosses are ultimately responsible for achieving results. Rather than doing all the work themselves, bosses rely on other people to achieve results, and will guide them accordingly. Scott goes on to unpick the aforementioned definition further, which I found very valuable (see Fig. 2 below).
  2. Trusting relationships are the key – For me, Scott’s point about the importance of building and maintaining “trusting relationships” is probably the crux of the book. Once a relationship of trust has been established, it becomes so much easier to practise “radical candor” on a daily basis. Unfortunately, there’s no set formula for developing trust. Scott, however, has identified two dimensions that help people move in the right direction: “Care Personally” and “Challenge Directly”.
  3. Care Personally – I was really pleased to read about Scott slashing the idea of people having two radically different personas – with people’s work persona being radically different to their private persona. Scott makes the point that you need to be your whole self to have a good personal relationship. She also talks about genuinely caring for the people who work for you as a critical prerequisite for a strong relationship. Unfortunately, I too often come across managers who regard the people that work for them as “resources” and treat them accordingly. Getting people to think more deeply about the “Care Personally” part of the trust relationship equation should help in stopping employees being referred to and treated as “resources.”
  4. Challenge Directly – “Challenge Directly” involves telling people that their work isn’t good enough. I personally have often found this the hardest part to do, as I’ve found there to be a fine line between challenging directly and (passive) aggression. Scott argues that challenging people “is often the best way to show them that you care when you’re the boss.” As counterintuitive as it may sound; challenging people directly can be a great way to establish a relationship. Challenging people, in a clear but constructive way, is often appreciated – despite it feeling hard initially (for both the poser and the receiver of the challenge). It shows (1) you care enough to point out both the things that are going well and the things that aren’t and (2) that you’re willing to admit when you’re wrong and that you’re committed to fixing mistakes that you or others have made. At the end of the day, it’s all about fixing a problem in my opinion.
  5. “Operationalising” good guidance – The book introduces a helpful matrix, which has four quadrants to consider in light of how to best care personally and challenge directly: “Ruinous Empathy”; “Manipulative Insincerity”; “Obnoxious Aggression” and – the desired one – “Radical Candor” (see Fig. 4 below). Scott stresses that each quadrant refers to guidance, not to personality traits. These quadrants are not used to label people, but to learn about the types of guidance we are or should be providing to the people we interact with. Having reflected on each of these quadrants, I found them to be very useful and ‘true’ (see Fig. 5 below).
  6. How to criticise without discouraging? – Scott mentions a number of useful tips on how to criticise people without discouraging the person. Also, it’s important to ask for criticism before giving it. As hard as it can sometimes feel, it’s important to actively and continuously ask for feedback, as a way of building a two-way relationship (see point 4. above). Scott provides some pointers to make it easier to ask for guidance, particularly from people that report into you (see Fig. 6 below). Secondly, be humble and helpful, offer guidance in person and immediately, criticise in private, and don’t personalise. Thirdly, make it clear that the problem isn’t due to some inflexible personality flaw, and share stories when you’ve been criticised for something similar.

Main learning point: Being radically candid doesn’t mean that you can just be rude and upset people. Instead, “Radical Candor” does a great job of offering readers with lost of valuable tips about how to care personally and challenge directly.

Fig. 2 – Former Secretary of State Colin Powell’s famous comment about sometimes having to piss people off – 


Fig. 3 – Unpicking the responsibilities that come with being a boss – Adapted from: Kim Scott. Radical Candor. pp 6 -7

  1. Guidance: Guidance is often called “feedback”. People dread feedback – both the praise, which can feel patronising, and especially the criticism. However, in order to solve problems or make the most of opportunities, people do need to solicit guidance from others, and encourage it between them.
  2. Team-building: Building a cohesive team means figuring out the right people for the right roles: hiring, firing, promoting. Once you’ve got your team in place, the focus should be on engaging with your team (without micro-managing) and keep people motivated.
  3. Results: Ultimately, it’s all about achieving results. As a boss it’s your responsibility to guide your team towards achieving key results.

Fig. 4 – Radical Candor’s “Care Personally Change Directly” matrix – Taken from:

Fig. 5 – Examples of the four quadrants of Radical Candor’s “Care Personally Change Directly” matrix – Adapted from: Kim Scott, Radical Candor, pp. 22-42

Radical Candor:

“I admire that about that you” is a great example of radical candid praise. It’s relatively easy to say “thank you” or “you’re awesome”, but it can be much harder to really think about the praise you want to give, personalise and contextualise it. For example, “I think the mentoring that you do is really impressive, I admire the way in which you take your own learnings and share them with people who are the stage that you were at a few year ago.”

Coming up with criticism when you’re being successful is probably a great time to apply radical candid criticism. I recently spoke to a senior executive whose company had just gone through a difficult patch, probably for the first time in its existence. “We’ve had it easy for so long” he explained to me. This comment made me wonder whether he and his colleagues would have benefited from a healthy dose of radically candid criticism whilst they were still winning. For example, “we just achieved over $10 million in revenue, and it has been a record year, but I think it’s important that we look at how to reduce our operational margins in the coming year so that this growth can become more sustainable.”

Obnoxious Agression:

A word of warning: “Radical Candor” isn’t about offering bosses a blank cheque to be rude or aggressive and act like a jerk. This is a lesson that I’ve been trying to take to heart, as I’ve experienced that there’s often a very thin line between being assertive and aggressive. Whilst I believe in directness over sugarcoating things , I’ve learned that 100% directness doesn’t work for everyone and can easily be perceived as aggressiveness. Scott’s point about the debilitating nature of Obnoxious Aggression therefore really resonated with me.

Manipulative Insincerity:

Manipulatively insincere guidance happens when you don’t care enough about a person to challenge directly. People give praise and criticism that’s manipulatively insincere when they are too focused on being liked or think they can gain some sort of political advantage by being fake – or when they’re just to tired to care or argue anymore. When you challenge directly, as Scott explains, you truly care about the people that you challenge; “let go of vanity and care personally.” The flip side happens when you don’t care and end up simply wasting your and everybody else’s time by trying to fake it.

Ruinous Empathy:

Scott claims that most people want to avoid creating tension or discomfort at work. Purely based on personal experience, I think Scott’s right; over the years, I’ve seen quite a few managers who actively try to make everyone happy. Whilst this is a laudable intention, I believe it hardly ever works like that. My personal mantra is that healthy tension doesn’t have to be a bad thing, it can actually help people grow and make teams more effective. You can’t be friends with all your colleagues nor can you make people happy all the time. Scott’s points about Ruinous Empathy made me think about how to best solicit feedback from team members, and ask for criticism. Scott urges all bosses to “start by asking for criticism, not by giving it!”

Fig. 6 – Soliciting impromptu guidance – Adapted from: Kim Scott, Radical Candor, pp. 130-136

  • Have a go-to question: In order to make it easier and less awkward to ask your direct reports for performance feedback or guidance, Scott suggest using a go-to question. She learned this technique from Fred Kofman, who used to be her coach at Google and is the author of “Conscious Business”. “Is there anything I could do or stop doing that would it make it easier to work with me?” This is just a sample to go-to question, the key goal here is to get the conversation going and to remove any feelings of awkwardness.
  • Embrace the discomfort: In case your go-to question fails to have the desired effect, and the other person answers that everything is fine or struggles to come up with something, remain quiet. It can be tempting to say “We’ll that’s great then” (or something along those lines) but that’s not going to help anyone in my opinion. Leaving some silence or suggesting to rearrange can help in getting your direct reports over their – understandable – hurdle.
  • Listen with the intent to understand, not to respond: If you’re anything like me, i.e. not super comfortable with asking people for feedback, your initial response might well be to act defensively and respond to the criticism. Scott urges us not to do that; don’t start criticising the criticism! Instead, she suggests saying something like “So what I hear you saying is …”
  • Reward criticism to get more of it: If you did get feedback, the next important thing is to follow up and show that you really welcomed the feedback. If you agree with what was said, you should make a change as soon as possible. If the necessary change will take time, do something visible to show you’re trying.
  • Gauge the guidance you get: I love Scott’s suggestion to try and keep a tally of the number of times people reporting to you have criticised you. Equally, measure how often they praise you. Scott mentions, that you should be weary it it’s all praise and no criticism! It means that you’ll have to work harder to get people to criticise you.


Related links for further learning:


Book review: “Just Enough Research”

Back in 2013, Erika Hall, co-founder of Mule Design, wrote “Just Enough Research”. In this book, Hall explains why good customer research is so important. She outlines what makes research effective and provides practical tips on how to best conduct research. Reading “Just Enough Research” reminded me of reading “Rocket surgery made easy” by Steve Krug and “Undercover UX” by Cennydd Bowles, since all three books do a good job at both explaining and demystifying what it takes to do customer research.

These are the main things that I learned from reading “Just Enough Research”:

  1. What is research? – Right off the bat, Hall makes the point that in order to innovate, it’s important for you to know about the current state of things and why they’re like that. Research is systematic inquiry; you want to know more about a particular topic, so you go through a process to increase your knowledge. The specific type of process depends on who you are and what you need to know. This is illustrated through a nice definition of design research by Jane Fulton Suri, partner at design consultancy IDEO (see Fig. 1).
  2. Research is not asking people what they like! – I’m fully aware of how obvious this statement probably sounds. However, customer researcher is NOT about asking about what people do or don’t like. You might sometimes hear people ask users whether they like a particular product or feature; that isn’t what customer research is about. Instead, the focus is on exploring problem areas or new ideas, or simply testing how usable your product is.
  3. Generative or exploratory research – This is the research you do to identify the problem to solve and explore ideas. As Hall explains “this is the research you do before you even know what you’re doing.” Once you’ve gathered information, you then analyse your learnings and identify the most commonly voiced (or observed) unmet customer needs. This will in turn result in a problem statement or hypothesis to concentrate on.
  4. Descriptive and explanatory research – Descriptive research is about understanding the context of the problem that you’re looking to solve and how to best solve it. By this stage, you’ll have moved from “What’s a good problem to solve” to “What’s the best way to solve the problem I’ve identified?”
  5. Evaluative research – Usability testing is the most common form of evaluative research. With this research you test that your solution is working as expected and is solving the problem you’ve identified.
  6. Casual research – This type of research is about establishing a cause-and-effect relationship, understanding the ‘why’ behind an observation or pattern. Casual research often involves looking at analytics and carrying out A/B tests.
  7. Heuristic analysis – In the early stages of product design and development, evaluative research can be done in the form of usability testing (see point 5. above) or heuristic analysis. You can test an existing site or application before redesigning. “Heuristic” means “based on experience”. A heuristic is not a hard measure; it’s more of a qualitative guideline of best usability practice. Jakob Nielsen, arguably the founding father of usability, came up with the idea of heuristic analysis in 1990 and introduced ten heuristic principles (see Fig. 2).
  8. Usability testing – Testing the usability of a product with people is the second form of evaluative testing. Nielsen, the aforementioned usability guru, outlined five components that define usability (see Fig. 3). Hall stresses the importance of “cheap tests first, expensive tests later”; start simple – paper prototypes or sketches – and gradually up the ante.

Main learning point: “Just Enough Research” is a great, easy to read book which underlines the importance of customer research. The book does a great job in demonstrating that research doesn’t have to very expensive or onerous; it provides plenty of simple and practical to conduct ‘just enough research’.


Fig. 1 – Definition of “design research” by Jane Fulton Suri – Taken from:

“Design research both inspires imagination and informs intuition through a variety of methods with related intents: to expose patterns underlying the rich reality of people’s behaviours and experiences, to explore reactions to probes and prototypes, and to shed light on the unknown through iterative hypothesis and experiment.”

Fig. 2 – Jakob Nielsen’s 10 Heuristics for User Interface Design (taken from:

  1. Visibility of system status – The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
  2. Match between system and the real world – The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
  3. User control and freedom – Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
  4. Consistency and standards – Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
  5. Error prevention – Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
  6. Recognition rather than recall – Minimise the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
  7. Flexibility and efficiency of use – Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
  8. Aesthetic and minimalist design – Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
  9. Help users recognise, diagnose, and recover from errors – Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
  10. Help and documentation – Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

Fig. 3 – Jakob Nielsen’s 5 components of usability – Taken from: Erika Hall. Just Enough Research, pp. 105-106

  • Learnability – How easy is it for users to accomplish basic tasks the first time they come across the design?
  • Efficiency – Once users have learned the design, how quickly can they perform tasks?
  • Memorability – When users return to the design after a period of not using it, how easily can they reestablish proficiency?
  • Errors – How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
  • Satisfaction – How pleasant is it to use the design?


App review: Curve

I recently heard Shachar Bialick – Founder and CEO of Curve – talk about how the new Curve app will make it easier for small businesses to manage their financial lives. It prompted me to have a first play with the Curve app in iOS, which is currently available as a Beta release. This is what I learned:

  1. My quick summary of Curve (before using it) – I expect Curve to be able to aggregate all my (business0 credit and debit cards – and related account / transaction data – into a single place.
  2. How does Curve explain itself in the first minute? – When I open the Curve app, I’m presented with two key messages: “Welcome to Connected Money” followed by “Curve combines all your cards into one smart card and smart app”. When reading these messages, “data” is the first thing that comes to mind. How will Curve combine and display all my bank data into a single place (and in way that lets me understand at a glance what’s going on)?
  3. Getting started, what’s the process like (1)? – When I tap the “Get Started” button on the app’s landing screen (see Fig. 1), I then need to enter my email address. By continuing through the rest of Curve’s onboarding journey I automatically agree to its terms and conditions as well as its privacy policy (see Fig. 2). I like the sound of the “magic link” – Curve sending me an email which lets me sign in with one click – over having to add yet another password (see Fig. 3).
  4. Getting started, what’s the process like (2)? – The screen which shows me the different Curve packages to chose from is great. It’s a clear overview, no frills (see Fig. 4). However, I’m unsure whether I’ve got sufficient data or information to decide which package is most appropriate for me. Also, can I switch from one package to another? If so, how easy is that?
  5. Getting started, what’s the process like (3)? – From providing more detail about my business to entering my card, the user experience feels very seamless and intuitive. I did, however, wonder why I did not need to enter then name of my business after stating that I’m a business owner. I expected some link to the Companies House details of my business, similar to Tide Bank’s onboarding process. Overall, the Curve app does a good job in trying to keep the onboarding process as simple as possible and the process of adding my first card feels straightforward too (see Fig. 5-6).
  6. Getting started, what’s the process like (4)? – The messaging around the card verification process is ok, but I’m nevertheless not entirely as to why my card issuer needs to provide security and I’m unsure as to how long this will take (see Fig. 7). I wonder what I can (not) do whilst I am waiting for my card to be verified? Will I need to go through a similar process when I enter an additional card that has been issued by the same provider?
  7. Getting started, what’s the process like (5)? – I’m massively intrigued by Curve’s new “Go Back in Time” feature (see Fig. 8). Curve lets its users swap purchases paid on one card to another. It lets users select the purchase(s) that they want change the payment method for. By tapping “Go Back in Time” under “Transaction Features” to bring up the menu, users can choose their preferred card for that purchase. This feature is available for any purchase under £1,000 with the Curve Mastercard within 14 days from purchase. I’m not 100% sure how long Curve will be able to hold one to this feature, as I can imagine the different credit card schemes getting up in arms about e.g. delayed payments or not being able to recoup initial payment transaction costs.
  8. Did Curve deliver on my expectations? – Yes. Although I haven’t yet been able to add multiple cards and see a combined view of transaction data for those different cards, Curve does a great job at explaining the onboarding process at every step of the way and uses some simple, but nice UX practices along the journey.

Fig. 1 – Screenshot of Curve’s iOS opening screen


Fig. 2 – Entering my email into Curve and agreeing to Curve’s T&Cs and privacy policy


Fig. 3 – Screenshots of Curve’s sign in process


Fig. 4 – Screenshot of ‘Which Curve are you?’ screen on Curve iOS


Fig. 5 – Information to enter during the onboarding process on Curve’s iOS app


Fig. 6 – Adding my first card in the Curve iOS app


Fig. 7 – Card verification steps on Curve’s iOS app


Fig. 8 – Welcome screen and Curve’s ‘Go Back in Time’ feature


Related links for further learning:



My product management toolkit (23): customer empathy

A few weeks ago I attended the annual Mind the Product conference in San Francisco, where David Wascha delivered a great talk about some of his key lessons learned in his 20 years of product management experience. He impressed on the audience that as product managers we should “protect our customer”; as product managers we need to shield our teams, but ultimately we need to protect our customers and their needs.

Dave’s point really resonated with me and prompted me to think more about how product managers can best protect customers and their needs. I believe this begins with the need to fully understand your customers;  “customer empathy” is something that comes to mind here:

  1. What’s customer empathy (1)? – In the dictionary, empathy is typically defined as “the ability to understand and share the feelings of another.” In contrast, sympathy is about feeling bad for someone else because of something that has happened to him or her. When I think about empathising with customers, I think about truly understanding their needs or problems. To me, the ultimate example of customer empathy can be found in Change By Design, a great book by IDEO‘s Tim Brown. In this book, Brown describes an IDEO employee who wanted to improve the experience of ER patients. The employee subsequently became an emergency room patient himself in order to experience first hand what it was like to be in an ER.
  2. What’s customer empathy (2)? – I love how UX designer Irene Au describes design as “empathy made tangible”. Irene distinguishes between between analytical thinking and empathic thinking. Irene refers to a piece  by Anthony Jack of Case Western University in this regard. Anthony found that when people think analytically, they tend to not use those areas of the brain that allow us to understand other people’s experience. It’s great to use data to inform the design and build of your product, and any decisions you make in the process. The risk with both quantitative data (e.g. analytics and surveys) and qualitative data (e.g. user interviews and observations) is that you end up still being quite removed from what the customer actually feels or thinks. We want to make sure that we really understand customer pain points and the impact of these pain points on the customers’ day-to-day lives.
  3. What’s customer empathy (3)? – I recently came across a video by the Cleveland Clinic – a non-profit academic medical centre that specialises in clinical and hospital care – which embodies customer empathy in a very inspiring and effective way (see Fig. 1 below). The underlying premise of the video is all about looking through another person’s eyes, truly trying to understand what someone else is thinking or feeling.

Fig. 1 – Cleveland Clinic Empathy: The Human Connection to Patient Care – Wvj_q-o8&

I see customer empathy as a skill that can be learned. In previous pieces, I’ve looked at some of the tools and techniques you can use to develop customer empathy. This is a quick recap of three simple ways to get started:

Listen. Listen. Listen  I often find myself dying to say something, getting my two cents in. I’ve learned that this desire is the first thing that needs to go if you want to develop customer empathy. Earlier this year, I learned about the four components of active listening, from reading “The Art of Active Listening” . Empathy is one of the four components of active listening:

Empathy is about your ability to understand the speaker’s situation on an emotional level, based on your own view. Basing your understanding on your own view instead of on a sense of what should be felt, creates empathy instead of sympathy. Empathy can also be defined as your desire to feel the speaker’s emotions, regardless of your own experience.

Empathy Map – I’ve found empathy mapping to be a great way of capturing your insights into another person’s thoughts, feelings, perceptions, pain, gains and behaviours (see Fig. 2 below). In my experience, empathy maps tend to be most effective when they’ve been created collectively and validated with actual customers.

Fig. 2 – Example empathy map, by Harry Brignull – Taken from: “How To Run an Empathy Mapping & User Journey Workshop”

Problem Statements – To me, product management is all about – to quote Ash Maurya – “falling in love with the problem, not your solution.” Problem statements are an easy but very effective way to both capture and communicate your understanding of customer problems to solve. Here’s a quick snippet from an earlier ‘toolkit post’, dedicated to writing effective problem statements:

Standard formula:

Stakeholder (describe person using empathetic language) NEEDS A WAY TO Need (needs are verbs) BECAUSE Insight (describe what you’ve learned about the stakeholder and his need)

Some simple examples:

Richard,who loves to eat biscuits wants to find a way to eat at 5 biscuits a day without gaining weight as he’s currently struggling to keep his weight under control.

Sandra from The Frying Pan Co. who likes using our data platform wants to be able to see the sales figures of her business for the previous three years, so that she can do accurate stock planning for the coming year.

As you can see from the simple sample problem statements above, the idea is that you put yourself in the shoes of your (target) users and ask yourself “so what …!?” What’s the impact that we’re looking to make on a user’s life? Why?

Main learning point: Don’t despair if you feel that you haven’t got a sense of customer empathy yet. There are numerous ways to start developing customer empathy, and listening to customers is probably the best place to start!

Related links for further learning:



Book review: “Good Strategy. Bad Strategy”

I came across a senior executive a few months ago, let’s call him “Bob”, who talked me through his startup’s strategy. In short, Bob showed me three ‘strategic pillars’ for the business. Each pillar contained a load of specific products and initiatives. When I asked Bob about the strategic challenges that his business was looking to tackle, I got a blank stare in return. My explaining the need for having clear business and product strategies unfortunately didn’t seem to resonate much with Bob …

This experience prompted me to read “Good Strategy. Bad Strategy” which was first published by Richard Rumelt in 2011. Two main questions drove me to pick up a copy of “Good Strategy. Bad Strategy”:

  • Is this going to be yet another strategy book, with lots of buzz words but little tangible content!?
  • How can I clearly articulate what constitutes a good strategy and what makes a bad one?

Ultimately, I want to improve the way in which I take people like Bob on a ‘strategic journey’, helping them to convert their goals into proper strategies. “Good Strategy. Bad Strategy” definitely delivered on this objective. Firstly, it paints a good picture of the problem space surrounding strategy. The first part of the book is all about common misconceptions about strategy and explaining ‘why’ there’s so much bad strategy around. Secondly, the book then outlines what is needed to create good strategies, explaining what goes into the “kernel” of good strategy.

Bad strategy

“Good Strategy. Bad Strategy” starts off listing some of the hallmarks of bad strategy:

  • Fluff – Fluff is a form of gibberish masquerading as strategic concepts or arguments. For example, I believe that terms like “seamless” or multi-channel have become so overused that they have lost a lot of meaning.
  • Failure to face the challenge – Bad strategy fails to recognise or define the challenge that a company is facing. Bob’s strategy was a good example in this regard. His strategy provided a number of solutions without the underlying strategic problems or challenges they were intended to resolve.
  • Mistaking goals for strategy – Many bad strategies are just statements of desires rather than plans for overcoming obstacles. For example, phrases such as “entering new markets” or “becoming the leading [fill in any sector of your choice here]” leave me wondering “why?”. These high level goals fail to highlighting specific strategic obstacles or opportunities a business is facing.
  • Bad strategic objectives – A strategic objective is set by a leader as a means to an end. As  Rumelt explains, “strategic objectives are “bad” when they fail to address critical issues or when they are impracticable.” For example, if the strategic objective is “to become a world leading furniture maker”, I’d argue that this is a vision statement and not a strategy. A related strategy would describe some of the key challenges to overcome in order to achieve the vision. Rumelt goes one step further by arguing that Google’s “vision mission strategy” template often misses the mark, as he feels it doesn’t cover true analysis of the challenges and opportunities ahead.

In short, in “Good Strategy. Bad Strategy” Rumelt makes the point that most strategies fail to acknowledge the key obstacles or problems companies need to overcome. I see an analogy with  the need to engage in a constant obstacle race, and businesses competing to overcome certain hurdles first.

Fig. 1 – Strategy as an ongoing obstacle race – Taken from:

So why is “bad” strategy such a common theme across so many businesses!?

The primary reason, as Rumelt highlights, is that bad strategy trumps analysis, logic and choice, with people hoping that they can avoid these often gnarly fundamentals and any issues in overcoming them. Rumelt stresses that “good strategy is very hard work”. I agree with this sentiment completely, as I’ve seen first hand that it can feel easier – in the short term at least – to ignore what’s happening or what could happen. Similarly, making strategic choices and deciding on tradeoffs is often very tricky and painful.

Good strategy

Rumelt describes the structure that underlies a good strategy as a “kernel” (see Fig. 2 below). The kernel of a strategy contains three elements:

  • A diagnosis that defines or explains the nature of the challenge. A good diagnosis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as critical.
  • A guiding policy for dealing with the challenge. This is an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis.
  • A set of coherent actions that are designed to carry out the guiding policy. These are steps that are coordinated with one another to work together in accomplishing the guiding policy.

In essence, the kernel forms the bare bones skeleton of a strategy. Aspects such as visions, hierarchies of goals and objectives or timeframes are typically left out of the kernel. These aspects are treated as support layers instead.

The diagnosis

Coming to a diagnosis is about, putting it simply, understanding what’s going on. For example, as soon as Bob and I started exploring the situation that his business was in, we came to the conclusion that it was operating in a market close to reaching saturation point. As Rumelt points out, “an explicit diagnosis permits one to evaluate the rest of the strategy.” In addition, by turning the diagnosis into critical part of the strategy, the rest of the strategy can be revisited as and when circumstances change.

The guiding policy

The guiding policy outlines an overall approach for overcoming the obstacles highlighted by the diagnosis. The guiding policy doesn’t commit to a specific set of actions. Instead, it rules out a number of actions and suggests an overarching method to deal with the situation as described in the diagnosis. For example, one’s guiding policy could be to focus on improving the lifetime value of existing customers as opposed to acquiring more new customers that conduct one-off transactions.

Coherent action 

Rumelt points out a common mistake people often tend to make by calling the guiding policy a “strategy” and subsequently stop there. Strategy is all about taking action to overcome obstacles or seize opportunities. This doesn’t mean that you need to outline every single proposed action in its finest detail, but at least provide sufficient clarity to help make certain concepts more realistic and tangible.

Fig. 2 – Maz Iqbal, Kernel of Strategy – Taken from:

I felt that thinking about the kernel of strategy makes it easier to then figure out some of the strategy’s support layers:

  • Taking a strong position and creating options – Rumelt disagrees with strategic thinkers that feel that in uncertain and dynamic environments, companies do well to plan ahead as much as possible. In contrast, Rumelt argues, the more dynamic and uncertain the situation the more proximate a strategic objective should be. He cites President Kennedy announcing the US’ ambition to land a person on the moon by the end of the 1960s as a good example of a proximate goal. Despite not knowing exactly how or when the US could land a person on the moon, the US had done enough research and testing for President Kennedy to feel confident about taking a strong position (i.e. committing to the first moon landing) and to exploring various options to get there.
  • Hierarchies of objectives – In organisations of any size, high-level proximate objectives create goals for lower-level units, which, in turn, create their own proximate objectives, and so on and so forth. I really like Rumelt’s related point about proximate objectives cascading and adjusting over time, as it does justice to the uncertain and dynamic nature of most of today’s market environments.

Main learning point: “Good Strategy. Bad Strategy” is a great book for anyone slightly at loss where to begin when it comes to creating or evaluating a strategy. In the “kernel of strategy”, the book offers a very useful structure to underpin every (good) strategy.

Related links for further learning:


App review: Toutiao

Fig. 1 – Screenshot of homepage 

When I first heard about Toutiaou I thought it might be just another news app, this coming one from China. I learned, however, very quickly that Toutiaou is much more than just a news app; at the time of writing, Toutiao has more than 700 million users in total, with ore than 78 million users reading over 1.3 billion articles on a daily basis.

Toutiao, known officially as Jinri Toutiao, which means “Today’s Headlines”, has a large part of its rapid rise to its ability to provide its users with a highly personalised news feed. Toutiao is a mobile platform that use machine learning algorithms to recommend content to its users, based on previous content accessed by users and their interaction with the content (see Fig. 2).

Fig. 2 – Screenshot of Toutiao iOS app

I identified a number of elements that contribute to Toutiao’s success:

  1. AI and machine learning – Toutiao’s flagship value proposition to its users, having its own dedicated AI Lab in order to constantly further the development of the AI technology that underpins its platform. Toutiao’s algorithms learn from the types of content its users interact with and the way(s) in which they interact with this content. Given that Toutiao users spend on average 76 minutes per day on the app, there’s a wealth of data for Toutiao’s algorithms to learn form and to base personalisations on.
  2. Variety of content types to choose from – Toutiao enables its users to upload short videos, and Toutiao’s algorithms of will recommend selected videos to appropriate users (see Fig. 3). Last year, Ivideos on Toutiao were played 1.5 billion times per day, making Toutiao China’s largest short video platform. Users can also upload pictures, similar to Instagram or Facebook, users can share their pictures, with other users being abel to like or comment on this content (see Fig. 4).
  3. Third party integrations – Toutiao has got strategic partnerships in place with the likes of WeChat, a highly popular messaging app (see Fig. 5), and, a local online marketplace. It’s easy to see how Toutiao is following an approach whereby they’re inserting their news feed into a user’s broader ecosystem.

Main learning point: I was amazed by the scale at which Toutiao operate and the levels at which its users interact with the app. We often talk about the likes of Netflix and Spotify when it comes to personalised recommendations, but with the amount of data that Toutiao gathers, I can they can create a highly tailored content experience for their users.

Fig. 3 – Screenshot of video section on Toutiao iOS app 

Fig. 4 – Screenshot of user generated content feed on Toutiao iOS app


Fig. 5 – Screenshot of Toutiao and WeChat integration on Toutiao iOS app

Related links for further learning:





My product management toolkit (22): how to create a product culture?

What can you do when you’ve joined a company that hasn’t (yet) got a proper product culture? Making it harder for you to do your job or get people’s buy-in. Unfortunately, this tends be harsh reality for a lot of product managers, who then become increasingly frustrated with a lack of progress or an unchanged mindset.

However, there’s no need to despair, as there are a number of techniques and tools to start instilling a product mindset and creating a product culture. In this piece, we’ll first define what product culture means and then explore ways in which you as a product manager can contribute to the creation of a product culture.

What is product culture?

Fig. 1 – Martin Eriksson, “What Is A Product Manager?” – Taken from:

If you look at the famous product management venn diagram by my friend Martin Eriksson it quickly becomes apparent how the three components of Martin’s diagram feed into my components of a strong product culture:

  • Customer understanding – We all know how easy it can be to pay lip service to ‘customer empathy’ or ‘understanding user needs’! However, a strong product culture begins and ends with your customers. In organisations with a strong product culture, all staff members interact with customers or are at least fully aware of their customer needs. Companies like Zappos and Amazon are well known for their focus on customer centricity factors (see Fig. 2 below). In my experience, signs of  non customer centric companies are those where only a small part of the business ‘owns’ the customer relationship or where the customer has become this imaginary persona for most staff members. Also, I encourage you to pose a healthy challenge to those people in the organisation who claim to “know what the customer wants” based on their experience.
  • Everything is geared towards creating great products – Throughout the company with a strong product culture one can find a strong sense of innovation, a desire to experiment in order to create great products. Etsy is a good example of a company that develops new products and services iteratively, constantly testing and improving on previous product releases. One of the telltale signs of a strong product culture is when employees possess what Marty Cagan refers to as a product mindset (see Fig. 3 below).
  • Value proposition and business model – A shared understanding of your business’ value proposition and business model is a clear sign of a good product culture. Alignment around the value you’re aiming to provide to your customers – combined with an awareness of who those customers are – is a critical part of a strong product culture, as it underpins the products and services that you put out there.
  • Curiosity and experimentation – You know that things could get challenging if you, as a product manager, turn out to be one of the few people in an organisation to ask ‘why’ and be curious. These are traits that can be learned and adopted, and the more innovative and customer centric businesses are those that aren’t afraid to be curious, learn and ‘fail well’. I heard a colleague of mine phrasing it quite well the other day when he spoke about “taking calculated risks”. In other words, taking risks in such way that you learn a lot – quickly and cheaply – about your riskiest assumptions, whilst any negative ramifications are limited or non-existent.


Fig. 2 – Steven MacDonald, How to Create a Customer Centric Strategy for your Business – Taken from:


Fig. 3 – Marty Cagan, Product Mindset vs IT Mindset – Taken from:

  1. Purpose.  In an IT mindset organisation, the staff exists to service the perceived technology needs of “the business.”  In a technology-enabled product organisation, the staff exists to service the needs of your customers, within the constraints of the business.
  2. Passion.  In an IT mindset organisation, product and technology are mercenaries.  There is little to no product passion.  They are there to build whatever.  In a product organisation, product and tech are missionaries.  They have joined the organisation because they care about the mission and helping customers solve real problems.
  3. Requirements.  In an IT mindset organisation, requirements are “gathered” from stakeholders, prioritised in the form of roadmaps, and implemented.  In a product organisation, we must discover the necessary problem to solve or product to be built.
  4. Staffing.  The IT mindset shows up very visibly in the staff and the roles.  The lack of true product managers (especially strong product managers), the lack of true interaction designers, the prevalence of old-style project management, engineers unfamiliar with the demands of scale and performance, the existence of old-style business analysts, and heavy use of outsourcing, are all clear examples of this.  I would argue the most telling manifestation of the IT mindset problem is that the product managers in IT mindset companies are typically very weak, and at true product companies they are necessarily very strong.
  5. Funding.  In IT mindset companies you find them still funding projects (output) rather than product teams measured by business results (outcome).   There are many serious problems with this antiquated model, and it generates all kinds of bad behaviour in the organisation as they try to work around the constraints of this system, but most importantly, it results in very poor ROI for the company because of the very high cost of finding out which ideas work and which don’t.
  6. Process.  In IT mindset companies, you usually find very slow, heavy, Waterfall processes, even when the engineers consider themselves Agile.  The only part that would be considered Agile would be at the tail end of build, test and release.  Much of this stems from the Funding issue above, but deciding what areas to invest in, staffing a team, defining and designing the solution, and release planning are all typically very Waterfall.  Technology-enabled product organisations simply must move much faster, and work differently, in order to deliver the necessary solutions for our customers and our business.
  7. Silos.  In IT mindset companies, people align by function, creating silos between the different areas of the business, product, user experience design, engineering, QA and site operations.  In contrast, in a product organisation, we depend on true collaboration between product, user experience design, technology and the business units.  In a product organisation we optimise for product teams, not for the individual functions.
  8. Organisation.  In IT mindset companies, engineering is often under a CIO, and “product” (if it exists at all) is often under marketing or absorbed directly in the business units themselves.  In product organisations, there’s a big difference between the engineers that support “true IT” and those that work on the commercial products,  The True IT engineers usually report to the CIO, and the commercial product engineers report to a CTO.  Similarly, product is not a sub-function of marketing.  It is a top-level activity on par with marketing and technology.  It is not so much the org chart that matters here, as much as a recognition that the way we manage True IT work is very different than how we manage commercial product efforts.
  9. Accountability.  In IT mindset companies, accountability frankly is a farce.  The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due.  In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault.  So management writes it off as yet another failed technology initiative.  In contrast, in a product organisation, we are measured by results.
  10. Leadership.  As with so many things, much of this boils down to leadership.  In IT mindset companies, the technology is viewed as a necessary evil.  It is a source of fear more than a source of inspiration.  Leadership in IT mindset companies is always looking for a silver bullet when it comes to technology.  Maybe they should outsource the whole mess?  Or maybe they can acquire someone else that hopefully has a better track record than they do.   In contrast, in a product company, technology enables and powers the business.  It is embraced and valued.  The people that create the technology are respected as the key contributors they are.  Leadership in a commercial product company understands that it’s their job to create the culture and environment necessary to nurture continuous innovation.

Where to start?

As daunting it may sound, starting to create a product culture doesn’t have to be overly complicated or onerous. As always, my advice is to smart small. Kick things off with some simple but targeted initiatives:

  • A visioning workshop to create a shared product vision – A product culture starts with a shared vision of what the product is (not), and what we’re trying to achieve with it for our customers and our business. Lack of a shared vision usually manifests itself in a product that wants to be too many things to too many people. As a product manager you can drive both the creation and the shared understanding of a product vision, starting with the facilitation of a visioning workshop.
  • Agree on a mission statement (and make sure it’s omnipresent) – Whereas a product vision is typically more aspirational and future oriented, a mission statement is all about the problems your business is aiming to solve right now (see Fig. 4-5 below).
  • Live and breathe clear values that underpin your (product) culture – Naturally, every organisation will have its own unique values – both explicit and implicit. However, there are a number of values that I believe underpin most product cultures: curious (see above under “what is product culture?”), courageous, innovative, open, trying and learning. Formulating and agreeing on such values is the easy part; truly embodying them on a daily basis tends to be much harder. For example, within my current product team, we’ve got a ‘team manifesto’ which encapsulates our core values and principles, and we use this as a living reference point, asking ourselves regularly whether we’re actually living up to our principles.
  • 5 simple ways to become more customer centric – Especially if you find yourself in a business with an IT mindset (see Fig. 3), bringing the customer into the picture can be difficult. However, I’ve discovered and applied five simple techniques that have helped me in making organisations and colleagues to think more about the customer and their needs (see Fig. 6).
  • Hire and fire for the right behaviours and values – A successful product culture depends heavily on the people within the organisation. This means that when you’re hiring product people, you’ll be looking for some of the key values that underpin your product culture. For instance, when I recruit new product people, I always try to filter out any ‘product janitors’ as quickly as I can, simply because it doesn’t fit with the values that I’m trying to instil into my product teams. Equally, this also implies that you sometimes need to make tough decisions and fire those employees who might be great people but don’t form a good fit with your product culture and its underlying values (see above).
  • Clear goals, celebrate success and failure – Outcomes over outputs. I understand people’s obsession with certain features or ideas, but I believe that businesses benefit from a continuous focus on goals and problems instead of of fretting over features. I’ve found a goal-oriented roadmap to be a great tool in terms of driving an understanding of common goals.
  • Continuous learning – In my experience, the ‘learning’ aspect comes from continuously exploring different ways to tackle a problem, celebrating success as well as reflecting on the ‘failures’. The more you can share these learnings with the wider organisation, the better. This helps in creating a culture where there’s full transparency with regard to both achieved results as well as those things that didn’t go according to plan. In turn, this breeds a culture of experimentation, taking calculated risks, experimenting and being open about the outcomes, whatever they are.


Fig. 4 – Elements of a mission statement:

For (target customer)

Who (statement of the need or opportunity)

The (product name) is (product category)

That (key benefit, compelling reason to buy)

Unlike (primary competitive alternative)

Our product (statement of primary differentiation)


Fig. 5 – Mission statement examples from Patagonia and Cradles to Crayons – Taken from:


Fig. 6 – How do we become more customer centric – Five simple ways to get there:

  1. 5 customers every fortnight – User research and usability testing don’t have to part of massive projects, getting input from thousands of customers. In contrast, engaging with 5 (target) customers every two weeks goes a long way in my experience. It gives you an opportunity to learn continuously, in tandem with your development work and product / feature releases.
  2. Team based user research – I learned from UX expert Erika Hall about the importance of collaborative or team based research. The key point here is that user research isn’t a one person job. People across the business will benefit from learning from and about their customers.
  3. Exposure hours – Similar to team based user research, the idea behind so-called exposure hours is to share customer learnings directly with team members and stakeholders, by them sitting in on a user interview for example and being directly exposed to customers.
  4. Feeling what users feel – In my previous company, Notonthehighstreet, we had a programme called “In Your Shoes” which meant that all employees had to spend one day at a customer and be part of their businesses and lives for a day. It was a great to experience first hand the problems and needs customers have, and understand their contexts better.
  5. Product retrospectives – Finally, I’ve found product retrospectives to be a great way of instilling a more customer focused mindset. Regular product retrospectives are a great opportunity for a team and the wider business to reflect on its products or services. How are our products performing? What did we release last month and how is that release doing? What are our customers saying, thinking and feeling? Product retrospectives are explicitly not about the team or process improvements. Instead it’s all about the product and its users.

Main learning point: Creating a product culture is by no means easy but as a product manager there are number of tools and techniques one can use to instil a product mindset and a more customer-centric approach.

Related links for further learning: