Show me the money framework for improving decision making skills

PC: Michel Curi

2017 was the year I agonised over buying a Tesla Model X. I ran through all the reasons I needed it — beautiful, gorgeous, drives fantastic, best technology and green. I just couldn’t come to a conclusion, because the price was a serious consideration. The problem at hand was that the reasons I wanted to buy it were intangibles.

That brings us to a key component in decision making — what do you do when you are facing a decision and there are numerous intangibles at hand? Paraphrasing Lord Kelvin, the famous British physicist, “The challenge of intangibles — when you can measure something and express something in numbers, you know what you are speaking about. If you cannot speak about it in numbers, then the knowledge is meager and you have scarcely advanced the state of science.”

As I looked around in other areas of my life, I saw that there were a number of other decisions that I couldn’t make progress on. They were also stuck because of intangibles. Some good examples that come to mind in the life of a product manager are: the value of open source software, when your product is driven by OSS; the value of adoption of open source software; what does virality mean for success of a product — how much should we be investing in virality; how to choose between competing features to make the most impact for the organization. I could talk to these decisions very well, had anecdotal evidence and experts backing those decisions…but they fundamentally were intangibles.

I have always been fascinated by literature on decision making and find that most recommendations range from “Just do it” to mind-numbing, if-then-else analysis. Douglas Hubbard presents a scientific, probability-based framework to reduce uncertainty through your decision making progress.

Paraphrasing Hubbard, “Decisions fundamentally are about a choice in the path ahead where decision makers have imperfect information. This lack of information causes uncertainty. Measurement is a type of choice among others to reduce this uncertainty. For any decision, you can typically measure a large combination of things, but you can never achieve perfect certainty.”

Thus, the right way to think about decisions is that a decision is a decision because one cannot articulate the right value of each of the choices ahead. The way to reduce the uncertainty, then, is to measure the things that reduce that uncertainty, knowing fully well that you cannot — and should not — measure everything that informs the decision, because too much information causes information overload. The key part of measurement is to assign an economic value to the measurement. Let’s say, you as a decision maker are looking to improve delivery of value from the organization. Measuring productivity of employees could be a type of measurement, and instead of measuring how much time an employee spends on each of the activities, quantify the business value of each of the areas she spends most of her hours on. Thus, if you get the employee to spend more time on activities that drive more business value, you can get more productivity from the system.

So how does one proceed, so that one isn’t stuck at the end of a spectrum that has “just do it” as the starting point and “analysis paralysis” as the ending point?

The ladder of better decision making starts by stepping back and questioning the decision. Check if you are asking the right question. Most hard problems in life and business can be solved by asking the right questions. If you are indeed asking the right question, then do the following (Hubbard calls it Applied Information Economics; with some color from my past readings on this topic).

  1. Define the decision. If the decision isn’t informing a significant bet, don’t measure anything. If the decision is easily reversible, just make a decision and move on.
  2. Determine what you know about the decision. Identify the key informational vectors that inform you more about the decision (hours working, vs hours spent on the most impactful activity).
  3. Compute the value of additional information (if none, go to step 5). Additional information is the information that you need to drill down into and measure.
  4. Measure where information value is high (return to steps 2 and 3). High information value implies tying some sort of economic benefit to it (improving productivity implied measuring and identifying most impactful hours). This really is the key to better decision making — tying some sort of economic value to your intangibles.
  5. Make a decision and act on it (return to step 1 and repeat as each action creates new decisions).

Typically, as you do steps 3, 4 and 5, you will find that each decision opens a cascade of micro-decisions that may have their own measurements to help build the case for the overarching decisions that you will rinse and repeat on.

So how did this framework help me?

  • I made the call on the Tesla before I read the book and was pleasantly surprised that my mental model roughly followed the framework. I put an economic value on each of the subjective axis, compared with the cost of the vehicle and came up short. I passed over the Tesla for a Lexus RX 350, knowing full well that I will evaluate my decision in the year ahead and these values may change — c’est la vie.
  • On the “business value” delivered by my team, I have instituted a “business value pointing” system offered by a tool called Aha. The vectors that constitute the business point are subjective. That is okay, because the scores on the vectors are informed by the expertise that my team has built up so far. We are drilling down on step 3 right now.
  • On understanding the “value of adoption of OSS” or “virality of a product” — I am on a journey and am hoping to find the right measurements to taking the decisions from “expert-led” to a state of science.

What decision frameworks work for you? Let me know in the comments section, below.

– Article heavily influenced by How to Measure Everything, by Douglas Hubbard.

Weekly newsletter #3 – 4 leadership principles to live by

f2939a09-702b-4e2f-bb5f-6ecf3bff82b1

I am in Maui this week and spent 2 days learning the theory on scuba diving only to discover that I failed and hated it. A blog coming next week about it. Meanwhile, here are the 9 things that I thought were worth sharing this week. Enjoy!

  1. [Leadership|Startup] My article on 4 key principles to become a good leader .
  2. [Life] Enjoy Tony Farhkry’s article about trusting the journey life is taking one on.
  3. [Work Life Balance]  Are you a workaholic?
  4. [Eye Candy]  Maui no words necessary!
  5. [Ear Candy]  Maui sound necessary!
  6. [Inspiration|Leadership] Simon Sinek’s “Start with the why” is seminal work – Ted talk and my book notes here
  7. [Health] Stu runs 1000+ miles without carbs. Read the exec summary from my book notes.
  8. [Picture] A billion caret diamond in Vatnajokull glacier in Iceland – one of mine :-).
  9. [Meditation] How to effortlessly move into meditation or fall asleep ;-).

Thanks for reading this newsletter, if you liked it forward it to a friend or tweet me some love. Past issues here.

Mahalo,
– Harpreet

If you want to be a good leader, live these 4 principles

“Look at what you have built – did you ever imagine that this was going to be so big?” A colleague asked me this question at a team event fairly recently.

My answer – “always”. I was confident in my response because I had laboured over for years on the degree of impact my/team leadership had on the realisation of goals dreamt years ago.

We had grown rapidly for years and I knew that I was doing something right but couldn’t boil it down to it’s essence. Then, a few years ago, I was at a Tony Robbins event where it struck me that I/our team was living the principles that he often talks about.

Principle #1: See things as they are

Not positive or negative but as they are. People usually fall into two camps: Glass half full or glass half empty.

The glass half empty camp looks at the world cynically – “things are never going to be better around here”. These are people that you should avoid – I know because I used to be one of them. I had role models who were cynical and responded to new ideas with a snarky comment – “Utterly uncool to try this new idea because it won’t work”… and it is devastating to effect any type of change.

The glass half full camp looks at the world optimistically – “things aren’t bad, they are actually wonderful and for the the stuff that doesn’t work, we will vision board the heck out of it”. I swung my pendulum from the cynical side to this side but slowly realised  that there always remained an incongruence between reality and the optimistic version which wasn’t healthy. Plus, one can never tell if things can get better because everything is pretty good to begin with. Ironically, wide-eyed enthusiast and a sceptic may end up achieving similar results. That said, I’d rather have an optimist on the team than a sceptic because coming into work is easy.

I have always looked for the buddhist “middle way” to bring disparate viewpoints together. In this case, the third way is that the glass is both half full and half empty at the same time and that is truly pragmatic.

Translated to leadership, the first principle is where you recognise the strengths and your weaknesses and your landscape. You aren’t irrationally optimist or pessimist but pragmatic.

This becomes all the more important in the startup world because your glass in a startup world is truly not half full but perhaps 1/8th full. You have some strengths and you have a number of weaknesses. Too often startups make mistakes because they either over-estimate their strengths “our key recipe is our secret algorithm that will make us successful” or under-estimate their weaknesses “we don’t need sales yet because our customer success team will create the necessary virality”.

Unless you have the capability to realistically assess where you are it is difficult to go to where you need to be. This brings me to principle #2.

Principle #2: See things better than they are

Essentially, know where the summit is where the flag has to be posted.

Why are you here in this businesses? You saw where things are and you know how to improve them. You have defined your why and  you will start your journey to the summit.  Some entrepreneurs do this very well but most are rather optimistic “we will change the world” … by bringing in app that sends a “yo” to someone-else – you get the point! This is why principle #1 is important comes before #2 to bring in pragmatism. As a leader, it is your responsibility to keep the audacious goals in the realm of achievability – usually this is backed by your domain and market expertise.

The eye-on-the-summit all the time is an important skill because others on your team won’t see it or believe it. I was often met with an incredulous look when I would call out the summit. Gradually, I learnt that some people cannot handle the summit height when they are at the base of the mountain and you have to break the summit down into series of milestones. I put people into circles and chose to expose the level of milestones, the summit or even multiple summits based on their capability to digest this information without freaking out.

 

Principle 3: Make things the way you see it

Easier said than done. You know the summit, where you are and then the journey begins. The journey is always two steps forward, 1 sideways, 1 forward and two backwards.

One of the key points that I have learnt here is that you need to be resourceful (Tony Robbins speak). Being resourceful implies doing a number of small experiments to see which ones work and tend to them further. I hate the term fail-fast because I find that fail-fast fosters a mental attitude of surrendering. I prefer that the investment in small experiments are based on hypothesis that are rooted in some prior work or research and then there is a healthy amount of investment done to prove or disprove the hypothesis.

Being resourceful also means to be out of a comfort zone tending into an eustress environment. A good marketing example is that writing a blog isn’t enough but getting it syndicated is called success; more so if syndicated on publications you have no prior relationship with. This will bring out the inner resourceful tiger in you. I have found that OKRs tend to foster the resourceful behaviour more than other commonly used management by objectives metrics.

Principle 4: Communicate, communicate and over-communicate

This was one of my most painful experiences growing as a leader. I would put the “plays” down, talk to the teams to make sure that everybody was on the same page and when I circled back, I found that there was a game of whispers going on and people were lost.

People don’t really listen the first, the second or the third time and when they don’t the empty vacuum is filled by conjecture or juxtaposition.

Over a period of time, I learnt to my job was largely defined to keep repeating the why, where we are and the goal post and I had to do that in one-on-ones, public setting, over drinks and dinners.

I have been doing these 4 principles repeatedly

My normal pattern for years has been been now to dive in, determine the landscape pragmatically, determine the north pole, start working on getting things to the north pole and communicate repeatedly on why we are doing on what we are doing.

These principles are (credit in huge part to Tony Robbins for laying them succinctly):

  1. See things as they are
  2. See things better than they are
  3. Make it the way you see it and
  4. Communicate repeatedly (TR doesn’t talk about this principle)

You have live these principles on a daily basis to truly bring your team forward. Tying back to my colleagues question to me on whether I dreamt of the success we would achieve – absolutely.

I’d really love to hear from you on this topic and if you decide to bring them in, share your experience with me. If you live by other leadership principles, share them with me too.

Ode to a warrior – a visual delight

While growing up in India, I chose French in school over Sanskrit. Twenty years later, my niece made the same choice despite me persuading her not to.

Why does an Indian kid with little chance of living in France choose French over his/her native language? Perhaps, we’ve been conditioned from the British raj days with the belief that anything western was better than Indian. So it didn’t matter to me if the french kids themselves were learning English but I had to take French to show a foreign language as my skillset. Ironically, I learnt the value of pride in my own culture after moving to the west.

This lack of schooling in Sanskrit is a deep regret because I cannot access a vast set of Indian literature that truly connects me to my past. Plus, I cannot enjoy spoken Sanskrit too – it is a mellifluous language where it seems that every word is meant to take you into trance. Try MS. Subbalakshmi for focus.

So how is the above rant related to the “ode to a warrior”?

I recently watched one of the biggest Telugu/Bollywood blockbuster from 2017 (Baahubali/2 – on Netflix) which is somewhat over-the-top in the Lord of the Ring genre of movies and I loved it.

This movie has a song where the hero is attempting to do something beyond mere mortals. There is an interplay of the description of a warrior within the context of a romantic song. The description of the warrior is done in Sanskrit while the romantic song is in Hindi/Telugu based on the version.

I fell in love with the Sanskrit lyrics but I had no idea what they mean. I had to google them and hence back to my regret of not being fluent in Sanskrit to enjoy it. So here are the verses:

Dhivaara, prasara shourya bhaara

O perseverant one, your bravery is taking you forward

Uthsara, sthira gambheera

You leap higher and higher, firm, stable and determined

Ugrama, asama shourya bhaava

You are strong and without an equal in the ability to fight 

Roudrama, nava bheetirma

Your anger causes new fear in your foes

Vijita ripu rudhira dhaara, kalitara shikhara kathora

Scaling impossible peaks, your blood flows like a rivulet

Kulakutara kulita gambheera, jaya virat veera

Your sturdy body itself is a sharp weapon because of his determination to win. Hail this complete hero of the world.

Vilaya gagana tala bheekara, gharjjhadvaara haraa

The hero is destructive in the air/sky as well because he can leap at an enemy from a great height. He can defeat the enemy simply with his fearsome roar of war.

Hridaya rasa kaasaara, vijita madhu paara haara

The emotion of victory makes you soft hearted after having the wine of victory. The hero is now about to complete the ascent of the mountain.

Bhayagaram shava, vibhava sindhu

You are the killer of fear with form of Shiva and Shakti and an ocean of wealth

Supara dhangam, bharana randhi

Now that the battle is over where Shiva has helped him win, a feeling of calm comes over him

(translation from Kumar Narasimha)

Gorgeous poetry!

I urge you to take 5 minutes to watch this video which is both an audio and a visual delight where the hero is pulled towards his goal. Loved it!

The superhero anti-pattern in scaling teams

15 Mar 2018

You know her; you have seen him in action; and too often you have been one — a superhero who flew down, laid yourself on the broken tracks and let the train pass over your shoulders and saved the day.

Have you been one? I know I have.

There is an escalation from a customer that has to be solved and a colleague has worked round the clock to bring it into the release schedule and will soon the solution will make it’s way to the customer.

Absolutely the right thing to do!

So what’s wrong with this approach?

The answer to my follow up question “so what moved out to make way for this escalation?” and the answer was “nothing, we pulled it in”.

Why is this a problem?

Occasionally becoming a superhero is a much desired attribute in a team member as it shows initiative, dependability in a team member. Done too often it shows organisational issues.

A superhero anti-pattern is an opportunity to unmask the following issues

The team is under-staffed

Too often, the team has a charter way bigger than they can handle and people need to be superheroes all the time. This over a period of time is going to impact the team credibility, morale and general well-being of the team members.

Not enough processes

Process is a maligned word but a good process in place is the world of difference between a teams ability to scale and respond to changes.

Too many escalations by too many stakeholders

Every person in the organisation has a direct access to any of the team members. “After all open communications is our thing!” The problem is that the team ends up responding and clarifying things to every person within the org and that sets the team up for failure. Recently, a colleague introduced me to the role called “the disturbed” which nominates a person on the team that takes the disturbances for a short period of time and keeps everyone focussed on their tasks. In this case, we are nominating one super-hero proactively.

The team leader and the team is not learning

There aren’t enough retrospectives in play that help the team learn and improve.

The individual loves the superhero mode

Almost everyone enjoys responding to the urgent versus doing the important because too often the important thing is really hard to do and there is always enough time. Urgent on the other hand makes people look good — who doesn’t want to look good?

The individual is gaming the system and climbing the ladder

Raise enough red-flags, come in, save the day and look good — win kudos. This motivation is insidious and eats at the culture of the organisation and the morale of the team. Rooting this out is hard and can be done encouraging members to continually focus on the important and not the urgent. When urgency itself is not rewarded the behaviour will be greatly reduced.

The superhero anti-pattern rears its head (often) in organisations that are undergoing rapid scaling. The superheroes themselves will not have enough bandwidth to recognise the sub-optimal behaviour and its ramification on the organisations. It is an opportunity for leaders to step back and unmask underlying organisation issues.

So what about my colleague — turns out that all it took was a conversation to point out that lets not put undue stress on the system and indicate what downstream deliverables get impacted and reflect that in the plan. Once done it provided a breathing space to the team to confidently execute on their deliverables.

Running a successful product portfolio summit

03 Mar 2018

pm-summit-matterhorn

As product managers, product roadmapping and planning is one of the most rewarding activities that we do in our jobs. Determining the most valuable problems to solve and finding the shortest path to bringing them to the market is the engine that drives business growth.

The biggest challenge that I have encountered as the head of products is keeping the teams marching to the same drumbeat especially since CloudBees has grown at rapid clip. A quarterly product summit is one tool that I have found that works well but only if it has been organized well.

In this blog, I lay out the recipe for running a product summit. I tend to think of product management in a trifecta of product, process and people.
So let’s walk through the process and people as a means of finding the right product to build.

First Step – Go to Switzerland

Did I tell you that CloudBees has an office in Neuchatel, Switzerland? Going to Switzerland for work is one of the nicest perks that I get at CloudBees and unsurprisingly enough picking this location had an invigorating effect on people 😉

pm-summit-zermat

People

 

Identify the right people for the summit

It is all about getting the right players into the summit and getting inputs from the right stakeholders before the meeting. In our recent summit, I had brought in product management, product marketing, engineering tech leads, engineering managers and representatives from support and solution architect teams. Not all summits have so many teams but the most recent one was our yearly summit and one that will drive alignment for the rest of the year.  pm-summit-team-bridge

(It does help if your team isn’t jumping off a bridge :-))

Clarify the roles of each of the players in the summit and re-clarify the roles of each of the players

It is easy to lose the message in a distributed team. My experience is that I have to repeat things at-least 5-7 times before it filters through.

Assign owners within each of the sessions

Without a clear owner and a clear goal sessions tend to meander. This alludes to the next paragraph about the process. An owner has the onus to keep the sessions moving productively

Process

Identify the right tools for the job

At CloudBees, we use Aha for product management, storiesonboard for user story mapping and JIRA for engineering stories and story pointing. Let’s drill down.

Determining the highest business value features

A key (if not the only) aspect of a PMs job is to determine the highest business value feature and at CloudBees we spend significant time doing market/customer validation building this out.

An intense period of discussions happens before walking into the summit where the product manager has worked on identifying the key customer problems. This product (not agile) backlog has factored in the company OKRs, the business objectives by the product head (me), feedback from the field. These have been laid out into Goals, Initiatives and Milestones for the year ahead by quarters. As you go further out say 3-6-9-12 months, things get fuzzier so that we can react to what we learn on the ground. The features are fairly well thought out for upcoming quarter or two.

We assign business points to the features in this pipeline to identify the highest business value and all conversations in the summit are factored around these features. We are in early days of Aha! Rollout and I personally think they have solved it. Here is a sample of our past planning.

pm-summit-aha

Arriving at a loveable experience

Once we knew we had the highest business value features, we focused on solving the user journey for those projects and used user story mapping as our tool. This was done on the walls 🙂 and using storiesonboard to capture the stories for off-summit-work. Post-summit, they continue using storiesonboard for work. pm-summit-user-story
(Michael Neale a CloudBees co-founder engaged in the user journey conversations)

Estimating the effort required

Coming up with realistic and reasonable estimates was a key deliverable. Now that the team had business pointed features, user journey, they focused on coming up likely estimates to get these done. The team chose to focus on the upcoming quarter as the reasonable (and non-waterfallish) time window.

At the summit, the team took the features and broke them down into epics/stories which made their way to JIRA and then did rough story pointing with t-shirt sizes as their metric. Post-summit, the team has deep dived in the estimates for the upcoming sprints and honed and refined these estimates.

Post Summit Fun

As you can imagine that these activities leading upto the summit and during the summit were an immense and intense amount of work. The team took the opportunity of being in Switzerland to visit Zermatt (has to be one of the prettiest places in the world) to do some skiing. The time in Zermatt, also gave the team to reflect on what we achieved and celebrate the success and come back recharged.

pm-summit-team-matterhorn It also gave the team to settle scores with team members who committed to the deliverables on their behalf. pm-summit-kal-vig

Except for a few bad apples (cough Vig please don’t kill Kal), CloudBees is an incredible place to work in and I and my counterparts are hiring. So come on over and join the fun.

Framework for building loveable products

Recently, I came across a pictorial that showed all the products in the DevOps market and the sheer number was mind boggling. As the head of products at CloudBees, I am often asked about recipes to build standout products in such markets and I will share my thoughts here. I will speak in the context of the DevOps space but the lessons should apply elsewhere.

Challenges

A challenge in this space is that tools have been built by the tool users themselves or in other terms “experts have built for experts”. DevOps has been a ground up movement, tools are born because someone scratched their own itch. That is wonderful – the market space is validated! However, the early movement has become a democracy now – everyone is doing it. This implies that novices expect to come in and be productive but the tools aren’t suited for them. This is an opportunity to differentiate! A corollary of the above problem is that these tools have been around for dozen or more years and just like the roots of a tree have spread across the entire organisation and integrate with every conceivable tool in there. This is good news for your product from an adoption perspective but it literally means that you have to change the tires of a running car if you want to rethink your product. Me-too implementations can rethink the experience but usually end up as implementing toy use cases because it will take them a generation to catch-up and build for enterprise tools. This is an advantage for existing tools and an opportunity to differentiate!

Build Lovable Products

Standing out from other product requires building products that are clearly differentiated. There are a number of product levers that can be played around with to build this differentiation. Levers like ease of use, targeted use cases, better branding, lower cost. I will focus on the product because if the product isn’t right – fixing other things is like putting lipstick on the pig.

Screenshot 2017-09-11 17.46.38

What’s your organising principle?

An organising product principle is the guiding light-house that aligns the entire organisation. For example, at CloudBees, ours is “Build a lovable product experience”. We constantly ask this of ourselves and use it to make tradeoffs in hard situations. This principle is highly energising and motivating – who doesn’t want to build something kick-ass and the principle sparks of very interesting and deep discussions in the company

What’s your organising principle? If you cannot articulate it – start here first.

Who are you solving the problem for?

You always have to remember that there is human on the other side who is going to use the product. Too often, enterprise products solve for all possible personas with the intention to make everyone happy. This results in user experience that isn’t targeted enough and consequently lovable enough or in other words clear-as-mud :-). Too often, I see that product teams forget about the persona and it shows in the product. At CloudBees, everyone from the exec team, marketing, sales and ofcourse product management knows the names of these personas, their motivations and even their looks. We not only know them, but target product requirements for that persona. We trade-off decisions based on the persona. It isn’t uncommon to hear statements like “Ada would never use this, this feature is for Simon and we aren’t focussed on Simon in this release”.

So, know the persona and make it as real as possible for a differentiated product.

Who is your user? Where does she sit in the organisation that you are selling to?

Who is your buyer? What do they do after work?

What are the right problems?

Once you know the persona, understanding the key problems is crucial. Building a good body of problems (at CloudBees we call it problem statements) is a matter of interviewing the target persona – rinse and repeat. The lean startup movement is exclusively focused on finding the right problems and I encourage you to read it.

How often does your user have the problem that you are solving for?

Rethink UX: Build a lovable experience

Simplify – don’t solve for corner cases. Solve the 80% really well and provide an escape hatch for the remaining 20%. Most devops product want to solve 100% of use cases 100% of the time. This leads to really complex products that hurt the novices coming in. Think how can you reduce the surface area so that people are not taking customers into a dark alley. Reduce the decision points that customers make. More decisions equals paralysis and leads to a frustrating experience.

As a side note: In the DevOps world, products cannot ignore the last 20% because this is where advanced use cases are solved. The key is to provide extensibility points so that customers can scratch their own itch. Fundamentally, this implies architecting the product so that it is extensible and implies factoring this architecture choice early in the vision of the product. Make a product extensible isn’t something that can be tacked on. If you are evaluating a product in the DevOps world, ensure that it is extensible.

Simplification becomes easy once you have the persona and the right problem statements because you can ask the right questions. Are you adding more value by allowing the persona to do more or are you simplifying a persona’s life by reducing the steps in the process that the persona goes through every day.

Screenshot 2017-09-11 17.48.23 I strongly advocate for a market validation and research phase that happens prior to execution. This phase is usually for small, medium and large initiatives and not for a bug fix for example. Build mockups, prototypes and iterate. Iterate with design, iterate with engineering, iterate with support, iterate with sales and most importantly iterate with customers. This before any substantial piece of code is written. By the time a new feature set lands at engineering, it has to be vetted and certifiably lovable. Having an engaged customer advisory boards that have a good representation of your target personas is a compelling tool in a company’s tool set. Note: I am not advocating waterfall or agile – this is somewhere in the middle more towards agile.

Build a lovable team

A lovable product isn’t going to be delivered if the right team isn’t in the picture. The team should be a triumvirate of product, design and engineering. The roles should be clearly defined for the triumvirate. Invest in design, product management and engineering meaningfully. Too often, this part of the organisation is running at capacity keeping the fires down and then executives wonder why good products aren’t being delivered. Screenshot 2017-09-11 17.49.04

Product Management

The product professional owns the persona and the problems. She knows what needs to be solved for and has an idea how that should be solved but should not go about designing the solution. A product manager’s job should then ensure that engineering and design “get” the problem, closely work on building the right solution and validating the right solution. A product manager mocking something on paper and throwing it to engineering is perhaps the worst thing that you can do to build differentiated products.

Design

Design takes the problem and builds the solution and its user experience. The role of the product manager is to provide the right customer context so that the designer can design the right solution. Design should be empowered to stand up to engineering, product management and should own the user experience.

Engineering

Engineering comes in and keeps designers and product managers real. They help them understand the costs of the choices being made and then build them. By the time, the product feature is in execution, engineering should know the customer, the problem and design intimately.

Finally, provide time and space for these individuals to ruminate and think. Interesting solutions happen when you are bored and have taken your focus away from the daily fires. At CloudBees, product managers, designers have a day called “Product Leader Friday” to work on projects that expand the understanding of a persona for themselves or educate the knowledge of internal teams or evangelise something they care about. I am writing this article on my product leader friday!

Summary

Standing out in a crowded market does not happen magically. It requires deep product thinking, organisational frameworks and executive buy-in and support to make it happen. It then requires relentless work guided by organising principles that have been laid out earlier. That said, if I summarise things, the nub really is about three key questions:

Who am I solving the problem for? What problem should I solve for her? What’s the best way to solve her problem?

Simple enough!