Entrepreneur of the year goes to the old man on the street in Istanbul

Yesterday, I was at Emononu, a ferry station in Istanbul and spotted one of the most entrepreneurial person that I have seen. I was blown away by his entrepreneurial spirit.

IMG_6898.JPG
PC: Harpreet Singh

The Sultanahmet area in Istanbul is teeming with tourists and so if you are a tourist and have spent anywhere beyond a day or two, you get used to being approached by shop salesmen trying to entice you with their wares. I don’t want you to get an impression that these guys are in your face and asking you to see something without an iota of originality in their sales pitches (a la a phone vendor in a typical US mall). Almost all of the guys have a super interesting hook to start a conversation with you and bring you into their shops.

These sales guys set a high bar — they nail the cold call opening!

Perhaps the highest bar in selling was set by Ibrahim at the Tuncer Gift shop who by far has been amongst the best salesperson I have ever seen and I have worked with many. Ibrahim had a unique conversational style that differentiates him over everyone else. He differentiated himself as opposed to the goods while selling commodity goods through a shop. (See his TripAdvisor reviews). Perhaps, I need to write a blog about Ibrahim but I have digressed.

Now coming back to street vendors, my default reaction to street vendors — typically guys carrying tea, chips or other such sundries is a terse no. That’s just the way it is, I don’t want to hear or even see what the vendor is offering. I presume this is the reaction of most folks when approached by street vendors.

Anyways — so if I have painted the picture that between the high salesmanship standards by shop salesman, my general dislike to being approached by street vendors and the fact that this was my third day in Istanbul that it was a high bar for someone to standout.

Then, we saw him and lets call him Abu (Urdu for father) an elderly gentleman, perhaps in his late 60s or early 70s, with a weather beaten face. Not the ones that look tired and indicate a life endured by hardship but a weather beaten face with an underlying glow backed with a smile that shows a life well lived and worked hard with honesty and integrity. He was wearing a suit and in the middle of 24C day, it must have been genuinely warm. The suit was worn down too.

Abu had a canon camera around his neck and a a big bag slung over his shoulder.

The bag had a kodak photo printer hacked with a battery pack to provide power to the photo printer!

Abu, thus had positioned himself next to the ferry station of the Bosphorus tour and was reaching out to tourists who were waiting for the next tour to start at the dock and getting them to take a picture. His unique selling point, was a hard copy of your photograph. Not a regular tea vendor — that wasn’t for him.

Why did we give in and get a picture clicked?

He had a photo frame!!!

He was framing the pictures in a photo frame and I (Mr. Customer) got a choice between two colours. Totally unexpected and completely delightful (delighters anybody?).

This is interesting in itself while we were waiting and not really looking at him. We saw him from the corner of our eyes, he had just finished taking a picture of a Russian family and then get this — he offered them a choice of white or a black paper frame to go along with the picture. The guy had thought about everything — amazing.

When we saw the picture frame, my wife and me decided we have to take a picture from this enterprising human.

Here is the picture that he took for us.

Delightful product and elated customers

Now, I typically will not pose for pictures and Abu made us pose right for a great picture and he did that every other customer that we saw. All in the 30 seconds that it took him to take the picture while not speaking a word of english. Amazing!

I regret not taking his picture though :-(.

So Abu from my point of view has done everything right as a CEO of Abu, Inc.

  • Product — check. A high quality hard copy picture of your family while you wait impatiently to get on the Bosphorus tour. This is not the crappy grainy picture that comes from a Polaroid.
  • Marketing specifically packaging — a picture frame to enticingly frame your picture so that it doesn’t end up in a drawer somewhere. This is where Abu nailed it imo — he truly brought in the notion of a delighter and absolutely surprised his customers and delivered more than they signed up for.
  • Sales — Perfect timing to approach customers. There is about 10–15 minutes to spare between buying a ticket and boarding and people usually don’t have much to do but get bored watching the boats.

All this for 4TL or about $1!

I wonder how things could be so much different if he was in Silicon Valley — he could very well be running a successful company.

But then again, who says he is not successful?

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.

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.

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!

How do awesome products come about?

22 Feb 2017

Untitled

Getting to what customers want, not what they think they want, is key to the success of a product manager and consequently to the success of the product itself.

Product managers are usually bombarded with ideas for new features, improvements on features, bugs and often a direct ask from a customer. Whether these requests can be directly built into the product or need deeper research often depend on the lifecycle of the product. A great PM separates herself from mediocre ones by digging into customer conversations to find a bigger, better more value story for the customer and consequently for the product. A recent presentation that I saw used the model T image here is quite instructive and as a PM you don’t want to be trapped with a horse when your customer wants a car.

Horse before car (credit Wikimedia)

Here are some tips that great product managers use to nail customer research:

  • Go through support tickets: Support tickets are like being in an ER room, there is a level of urgent response that is required all the time. That said, a great PM discerns and finds the pattern in the issues and brings it into the product backlog vs jumping heroically on every issue. Support engineers are the heroes in the picture and there isn’t a need for another one. Remember Batman succeeds because Alfred exists.
  • Listen, listen and listen to the field: Your field (customer success, sales engineering, support) are direct lines to your customers. Listen to what they are saying. A good metaphor, is to think of the field as weather sensors and it is your job to discern the weather patterns over a region. The challenge often is that given the time/budget constraints, you won’t be able to build rain shelters in all the places (it is raining heavily in San Jose as I write this) and setting relevant expectations goes a long way. The advantage of getting the feedback from the field is that issues have been condensed and up-leveled to keep urgency away and focus on importance. Great PMs focus on getting to the problem and have discipline to ignore the solution that comes from field in some cases. A PM may get to the same solution but directly consuming a solution from the field or customer is laziness.
  • Get on customer calls with field: Be a fly on the wall and don’t actively participate on customer calls.
    • Don’t taint a customer call: By bringing in privileged knowledge that the field doesn’t have. Great PMs have to empathise with customers and understand the challenges that field faces
    • Actively propose product hypothesis to customers: Be active on some calls, you do need to push a product investment hypothesis to validate with customers.
    • It is hard choosing between the above two modes. So you decide upfront before you get on the call – know if you are a fly or going to pitch on the call. Know what’s what and notify your field counterpart accordingly before you get on the call.
  • Do customer visits: This is really the nub of getting feedback. I wrote a number of blogs about this aspect, so summarising here:
    • Be an intern: when you get to customers, tell them that you are an intern and let them walk you through how they deal with your product or problems in your domain.
    • Stop showing off: Do not offer any advice or show how they can solve the problem with the product before they have gone through the litany of issues. Hear through all the use cases and problems.
    • Pitch product at the tail end of the interview: it shouldn’t be all take, there is some give too :-). Pitch product if it truly solves the problem that they raised in the interview
    • Validate hypothesis: pitch what’s on your roadmap to validate if they will find value in what you build
    • Use power questions: “What’s on your mind” to begin interviews and “What else is on your mind” to end interviews. These do a really good job of exhausting the problem space that you can solve for. “Tell me more” is another great tip to get into details of a problem domain from customers.
    • Summarise: Finally, summarise the visits in internal wikis, share with other product managers and engineers. A customer visit should be used to expand understanding of a domain with everyone in the company.

Improvements in product or life, don’t happen magically or are solved magic bullets. Process changes and focusing on implementing processes is what brings success long term. Incorporate the above ideas in your customer research process and you will build great products.

What really is on your customers mind?

04 Feb 2017

Untitled

Recently I wrote 2 blogs (tell me more, be an intern) talking about tips to conduct an effective customer/prospect interview for product managers. This blog wraps up the tail end of that series.

One of the most effective power questions is “What else is on your mind”. I picked this one up from the Coaching Habit by Michael Stanier. In the book, Michael calls it the mother-of-all-power-questions (ok, you got me, I am exaggerating :-)). I often employ it with my team on the front end of a conversation to land at the key issue that is troubling them and can attest to its efficacy.

Flip the order of the question and ask it at the tail end of an interview.

The customer by this time has gone through his laundry list of “urgent” issues with you and peppered you with a few good important problems.

They are spent – or are they? Hmm…

Now the customer has to dig really deep and this thinking often brings out key problems that may not be very obvious. These problems are usually the ones that you want to solve as product manager or at least help the product manager understand the customer.

Mind-meld – did you say?

A recent example from an interview:

We were recently at a customer and found that they spent substantial amount of time build reports to understand their Amazon costs. The entire hour and a half that we spent there, this didn’t come up – after all they were talking about their Jenkins delivery pipelines. Even they were surprised to realise that the problem was more important to them than they originally thought.

Finally, a customer conversation cannot be rated highly if the product manager hasn’t documented the interview, shared and discussed it with the team, had a couple of compelling deep dive conversations with the customer again.

Be greedy with your customer

20 Jan 2017

Untitled

Finding the right problem, its details, from customer interviews are similar to finding an address in India.

A problem while looking for an address in India is that neighbourhoods are congested and the roads are not labeled. One uses landmarks to reach to the right area, find a shopkeeper to guide you to the next smaller neighbourhood landmark – rinse, repeat – recursion :-).

Similarly, customer interviews are an open-ended discovery process, you hope to find the right problem neighbourhood and then navigate the alley to find the right house. The “be an intern” phase gets you in the right neighbourhood. Getting to the right house means that the product manager wants to

  • gain a deeper understanding of the problem
  • validate earlier assumptions about the problem
  • validate if the solution hypothesis holds up in light of the new information

Tell me more or I would like to know more about…” is a power question that helps clarify and validate assumptions about the problem domain. This question is usually asked after you have poked around the obvious questions on what the customer has told you. In the initial discovery phases this can be used to narrow down the persona as in “tell me more about who has this problem” or understand the depth of the pain as in “tell me more about why this is so important to you”. In the latter phases, when you have prototypes or mockups, the question ends up validating your solution as in “tell me more if you care about this view” or “tell me more if you care about storing logs” or “tell me more about someone who does this well”.

Simple enough! Its power lies in its simplicity. Try it next time.

– Harpreet

 

Tip to conduct great customer interviews – Be an intern

16 Jan 2017

Untitled
Last week, I visited a CloudBees customer with Kohsuke Kawaguchi (Jenkins’ founder) to interview them. The goal was to understand their key challenges and concerns.

Over the years, Kohsuke and myself have done innumerable customer interviews together and somewhere along the way we have hit on a formula that makes for great customer interviews.

The formula is “Be an intern” (credit: as is usually the case with Kohsuke, belongs to him).

An advantage of tag-teaming is that one person takes copious notes while the other asks questions. The interview goes something like this (replace “software delivery process” by the key problem(s) your product solves):

The Interview

Us: Think of us as new interns on your team, now walk us through the entire software delivery process.

Customer: We were using your software and ran into so and so bug with your software.

Us: Hold on. We will definitely get to that. Right now, tell us why that is important as an intern. If not, lets go through your software delivery process

Customer: Uh ok, I guess it is not important as an intern. Ok – so we have a very typical software delivery cycle. We push the code and then we do a “official build” which is then tagged by QE as golden build.

US: Hold on – who is “we” – is this one team or many? What do you mean “typical” – is that in your group, across teams or standardised across your company”. What’s an official build – who calls it official? What does a golden build mean? Who is impacted with golden build? How long the process take?

And so on. You get the idea. The interview becomes very open ended and helps us be part of their team.

Advantages of this approach:

  • No ask-the-experts: Customer interviews are a critical learning process. When product (and in this case the founder of Jenkins) lands up at customers, customers want to jump at the opportunity to make the session as an “ask the experts” session. The intern approach avoids an “ask the expert session”
    • Deep learning of the problems: A distinct shift happens in the customer where they stop viewing you as the expert and start explaining how things should work. As a PM – this is where the key learning for the product happens.
    • Listening to the customer: When you are not the expert, you have no option but to listen – which is a tremendous skill to have as a PM. Listening to the customer is where you learn about the customer and importantly the customer feels heard before you tell them any solution.
    • Validation of the roadmap: The session becomes a “no pitch” session and product management mentally maps problem to the planned roadmap. The usual risk is that product management “shows up and throws up” while the customer sits with folded hands thinking if they should renew or not next year. When you hear the problems and can map to the roadmap, it is a huge validation (or not) to whats planned.
    • Explaining your solution/roadmap after listening to the customer: Once you have validated (or not) the roadmap, have heard the breadth and depth of customer challenges as part of this interview process, you lay out your roadmap and how your solution(or roadmap) helps address the key concerns that were raised in the interview.

If you are a product manager, I encourage you to use this as part of your quiver when you meet customers.

  • Harpreet Singh