Thursday, August 5, 2021

Talking versus doing

A few years ago i went to a retreat for young leaders/entrepreneurs. It was filled with random people, each having a different idea about what they were doing and how they are building products and companies. We also had speakers and workshops.

During one of the speaking sessions, there was a guy that told us about "product development" or "starting a company" - something in between those lines. It was a normal session, but one guy(he actually had a small profitable business) in the audience was really pissed at the speaker, contradicting him on various items and the settling on the conclusion "what do you know, you're a speaker, you're not an entrepreneur, you're not doing the actual blood, sweat and tears...". I was about 10 years younger then and i sided with the angry guy. At dinner, after a few drinks, the topic of the "speaker, not doer" popped up again. The speaker was also with us, at the table. After we finished dinner, we split into smaller groups. I was with the angry guy and the speaker, all a bit tipsy. The same argument popped up and the speaker did not have any plausible defense. In the end the argument was something like this

  • the speaker is presenting a model of how the world works
  • the model is generic, and you need to add context, your context, for it to make sense
  • the angry guy had either a different model, which was unclear to him to phrase it as a model
  • OR he rejected the speakers' model/parts of the model saying that his model(based on his successful experience) was different

We never reached an agreement, and the angry guy seemed to get his way and not accept any argument from the speaker that basically said: even if i did not do it myself, does not mean that my model is wrong(the gist).

Today, after 10 years (i'm slow AF), clarity hit me. There are all these self help books written by pseudo-successful or genuinely successful people, that take their experience and try to generalize it into a model, spanning too many pages. On another side, there are the scientists who write papers on really granular topics from a big whole like "entrepreneurship" or "opportunity identification". On yet another side there are some entrepreneurs, who, successful or not, made up their own model and have their own biases.

The speakers are somewhere under the scientists, many of them having no entrepreneurial experience(i'm generalizing to make a point) but somehow, they seem to know parts of some scientific models that the can successfully build into a narrative that is pleasant to listen to and makes sense under little or no criticism.

Problem now is: why is this clash between a person that know what they're talking about and another person that know what they're talking about. They cannot both be right. So, this got me thinking: what if they're not talking about the same thing? I, of course, assume that the speaker has reputable sources and also that the other person has a true experience.

We would need to separate these 2 ways

  • if they're talking to generic, then the conversation can be about 2 different things
  • if they are talking very specific
    • the speaker has less context
    • the other person has context but they may or may not understand the model

In both cases, they don't seem to understand each other. While thinking about a virtual solution would be fun, for example: they need some quiet time together to align on their models and assumptions and then, once they reach this agreement, to reason from there. If they could not reach this agreement, then any end result would be flawed. This solution needs certain types of personalities, context and setup. At the same time, this is not how the world works and it's not realistic.

As i'm thinking and writing at the same time, i don't seem to have a better conclusion other than: if "doing" does not have an accurate model of what has been done, and made wrong assumption and somehow was still successful - they might not be able to repeat the experience. "Speaking" might have an accurate model, but if it cannot be communicated clearly enough so the listeners can map their experience with the model, or even their next actions, it's easy to dismiss anything on the spot.

A more obvious conclusion is

  • don't make assumptions that if someone did not "do" they cannot teach you something
  • try to take your time to map your context on a model that is being presented, don't dismiss it too fast

I'm not even going to talk about self help books(yes, i'm dismissing them, sue me).

Sunday, June 14, 2020

Why context has more weight than i initially thought

In my journey of understanding i came across an important factor recently. Nothing beats your bias towards people than spending at least 1 hour talking to any person about any topic. And actually listening. While bias towards people tends to fall into a go/no go category(at least that’s the way i learned people judge others) the reality is much more complex. While it’s substantially easier to categorize people in fewer categories, i came to the conclusion that putting people in boxes is at least insufficient.

Here comes the first bias i encountered. Anchoring. This “helps“ you form an early and basic opinion about somebody as a whole, very early on, when you get the first signal about that person that you can relate to or oppose to. I have the impression that if you opposed something in the new person this bias gets activated faster. Maybe. I don’t know how to research this and it’s outside the scope of this text.

This occurred to me as a problem. I read something recently that focusing on what brings you and the other person together can truly maximize the potential of any interaction or relationship you have. When anchoring on something you disagree with from the start, you put on some glasses that never allow you to see the complexity of the other person because you’re just closed to ANY signals, regardless if you consider these signals as good or bad(this has nothing to do with reality, just your belief system and other biases). Small correction: you basically ignore signals that you might find positive and use the anchor, as when getting signals that you judge as negative, it usually counts towards doubling down on the initial negative anchor position. An actual first step is to do nothing. This is not as easy as it sounds. Doing nothing means refraining from something: using your anchor. Without this impediment you can actually start exploring the context.

I think the basic flaws of human understanding and collaboration are miscommunication and of course improper judgement(by this i mean drawing conclusions too fast on too little data). This sounds like another bias: overconfidence(will not get into this here, but feel free to google it).

I will not be specific in this text, because i want to present the model i discovered and the blocker at the end.

So, the first step is being “open” in simplistic terms, but as you saw above, doing nothing is not an easy task. Let’s assume you get over this step.

Once this is overcome, i think most misunderstandings and biases towards one another can be dealt with with at least 1 hour of honest communication. It does not have to be very personal, but it helps when you listen to the other person’s story: where did they come from, what decisions did they make at what time, what was their context back then etc. It basically boils down to:

  • what did the person know back then as in knowledge capital
  • what was the goal that person was striving for
  • how did the pieces come together for that person to make that specific decision that brought that person to the next important milestone

Repeat this until you get to today. While you go through the story, you will see another human being, with hopes, worries and fears, honest goals and decision making framework. As you start finding out more, you will see that although there might be values and principles you don’t agree with, put into context, everything starts to make sense. And with understanding comes, well, understanding. Which is something i value very much. Understanding let’s use get past the basic category mechanism and gives you a glimpse into the WHY.

This means two things:

  1. you now have data
  2. the data points are the ones with the most weight as seen by the other person(they’re basically saying: in a few words, this is how i got here, and trust me, i know because i’ve been there as the main actor)

They’re showing you their thought process, external factors they observed and how they connected the 2 into going to the next step. Wherever that is: jail, politics, industry, family etc.

Here comes the blocker.

Put yourself in a hypothetical situation: you are a judge which has basically 2 boxes(guilty or not). You need to be objective, unbiased and conclude on a category. All this, while knowing the context. The context makes sense, all the data that was truly available(not all the available data is equally accessible at all points in time, because each data point has a different weight which fluctuates over time) to that specific situation was somehow taken into consideration(not all decisions you make in your life permit you time to analyze and process your actions to their full potential, because you use your intuitive brain for time sensitive tasks or danger facing situations).

Now, when knowing all of this, it doesn’t just seem unfair to be categorized in only two boxes, but it’s insufficient.

Now put yourself in the position of the judge. You are refraining yourself from automatically categorizing into basic boxes and after understanding the context, boxes don’t make sense anymore. The complexity trumps the basic boxes. It’s a more abstract concept that does not only have a yes/no output. Each individual action might have, but looking at the whole, it’s not enough.

What do you do now? You basically demonstrated that your initial signal was not good/bad but the signal categorization activity was the wrong activity to apply. The less wrong activity was to get more data and understand the context better. Why, how, when, with whom and where.

Focus on the things that you have in common. While the context might be different, you both reached to the same point while traveling on different journeys.If you learn the other person’s context, not only you learn something new, but you gain a friend. The vast majority has good intentions. It’s really improbable that you actually meet a truly “bad” person.

Monday, November 18, 2019

The Common Denominator of Success


by Albert E.N. Gray
“The common denominator of success --- the secret of success of every man who has ever been successful --- lies in the fact that he formed the habit of doing things that failures don't like to do.”

THE COMMON DENOMINATOR OF SUCCESS is as timely and inspirational, as it was when it was first delivered in 1940. Though it was written for life insurance professionals, it's message is equally well suited to anyone in the sales profession, or anyone in any field of endeavor who seeks success in their professional, personal or spiritual lives.

This inspiring message by Mr. Gray is one of the most timeless pieces of life insurance literature. It first appeared as a major address at the 1940 NALU (National Association of Life Underwriters) annual convention in Philadelphia and has been available to association members in pamphlet form ever since. Although our author has passed away, his words of wisdom and moving philosophy --- so manifest in "The Common Denominator of Success" --- are part of the current life insurance scene and have real meaning for today's professional life underwriter. Mr. Gray was an official of the Prudential Insurance Company of America and had 30 years of continuous experience both as an agent in the field and as a promoter and instructor in sales development. He was known throughout the country as a writer and speaker on life insurance subjects.

Several years ago I was brought face to face with the very disturbing realization that I was trying to supervise and direct the efforts of a large number of men who were trying to achieve success, without knowing myself what the secret of success really was. And that, naturally, brought me face to face with the further realization that regardless of what other knowledge I might have brought to my job, I was definitely lacking in the most important knowledge of all.

Of course, like most of us, I had been brought up on the popular belief that the secret of success is hard work, but I had seen so many men work hard without succeeding and so many men succeed without working hard that I had become convinced that hard work was not the real secret even though in most cases it might be one of the requirements.

And so I set out on a voyage of discovery which carried me through biographies and autobiographies and all sorts of dissertations on success and the lives of successful men until I finally reached a point at which I realized that the secret I was trying to discover lay not only in what men did, but also in what made them do it.

I realized further that the secret for which I was searching must not only apply to every definition of success, but since it must apply to everyone to whom it was offered, it must also apply to everyone who had ever been successful. In short, I was looking for the common denominator of success.

And because that is exactly what I was looking for, that is exactly what I found.
But this common denominator of success is so big, so powerful, and so vitally important to your future and mine that I'm not going to make a speech about it. I'm just going to "lay it on the line" in words of one syllable, so simple that everyone can understand them.

The common denominator of success --- the secret of success of every man who has ever been successful --- lies in the fact that he formed the habit of doing things that failures don't like to do.
It's just as true as it sounds and it's just as simple as it seems. You can hold it up to the light, you can put it to the acid test, and you can kick it around until it's worn out, but when you are all through with it, it will still be the common denominator of success, whether you like it or not.

It will still explain why men have come into this business of ours with every apparent qualification for success and given us our most disappointing failures, while others have come in and achieved outstanding success in spite of many obvious and discouraging handicaps. And since it will also explain your future, it would seem to be a mighty good idea for you to use it in determining just what sort of a future you are going to have. In other words, let's take this big, all-embracing secret and boil it down to fit the individual you.

If the secret of success lies in forming the habit of doing things that failures don't like to do, let's start the boiling-down process by determining what are the things that failures don't like to do. The things that failures don't like to do are the very things that you and I and other human beings, including successful men, naturally don't like to do. In other words, we've got to realize right from the start that success is something which is achieved by the minority of men, and is therefore unnatural and not to be achieved by following our natural likes and dislikes nor by being guided by our natural preferences and prejudices.

The things that failures don't like to do, in general, are too obvious for us to discuss them here, and so, since our success is to be achieved in the sale of life insurance, let us move on to a discussion of the things that we as life insurance men don't like to do. Here, too, the things we don't like to do are too many to permit specific discussion, but I think they can all be disposed of by saying that they all emanate from one basic dislike peculiar to our type of selling. We don't like to call on people who don't want to see us and talk to them about something they don't want to talk about. Any reluctance to follow a definite prospecting program, to use prepared sales talks, to organize time and to organize effort are all caused by this one basic dislike.

Perhaps you have wondered what is behind this peculiar lack of welcome on the part of our prospective buyers. Isn't it due to the fact that our prospects are human too? And isn't it true that the average human being is not big enough to buy life insurance of his own accord and is therefore prone to escape our efforts to make him bigger or persuade him to do something he doesn't want to do by striking at the most important weakness we possess: namely, our desire to be appreciated? Perhaps you have been discouraged by a feeling that you were born subject to certain dislikes peculiar to you, with which the successful men in our business are not afflicted.

Perhaps you have wondered why it is that our biggest producers seem to like to do the things that you don't like to do.

They don't! And I think this is the most encouraging statement I have ever offered to a group of life insurance salesmen.

But if they don't like to do these things, then why do they do them? Because by doing the things they don't like to do, they can accomplish the things they want to accomplish. Successful men are influenced by the desire for pleasing results. Failures are influenced by the desire for pleasing methods and are inclined to be satisfied with such results as can be obtained by doing things they like to do.

Why are successful men able to do things they don't like to do while failures are not? Because successful men have a purpose strong enough to make them form the habit of doing things they don't like to do in order to accomplish the purpose they want to accomplish.

Sometimes even our best producers get into a slump. When a man goes into a slump, it simply means that he has reached a point at which, for the time being, the things he doesn't like to do have become more important than his reasons for doing them. And may I pause to suggest to you managers and general agents that when one of your good producers goes into a slump, the less you talk about his production and the more you talk about his purpose, the sooner you will pull him out of his slump?
Many men with whom I have discussed this common denominator of success have said at this point, "But I have a family to support and I have to have a living for my family and myself. Isn't that enough of a purpose?"

No, it isn't. It isn't a sufficiently strong purpose to make you form the habit of doing the things you don't like to do for the very simple reasons that it is easier to adjust ourselves to the hardships of a poor living than it is to adjust ourselves to the hardships of making a better one. If you doubt me, just think of all the things you are willing to go without in order to avoid doing the things you don't like to do. All of which seems to prove that the strength which holds you to your purpose is not your own strength but the strength of the purpose itself.

Now let's see why habit belongs so importantly in this common denominator of success.
Men are creatures of habit just as machines are creatures of momentum, for habit is nothing more or less than momentum translated from the concrete into the abstract. Can you picture the problem that would face our mechanical engineers if there were no such thing as momentum? Speed would be impossible because the highest speed at which any vehicle could be moved would be the first speed at which it could be broken away from a standstill. Elevators could not be made to rise, airplanes could not be made to fly, and the entire world of mechanics would find itself in a total state of helplessness. Then who are you and I to think that we can do with our own human nature what the finest engineers in the world could not do with the finest machinery that was ever built?

Every single qualification for success is acquired through habit. Men form habits and habits form futures. If you do not deliberately form good habits, then unconsciously you will form bad ones. You are the kind of man you are because you have formed the habit of being that kind of man, and the only way you can change is through habit.

The success habits in life insurance selling are divided into four main groups:
  1. Prospecting habits
  2. Calling habits
  3. Selling habits
  4. Working habits
Let's discuss these habit groups in their order.

Any successful life insurance salesman will tell you that it is easier to sell life insurance to people who don't want it than it is to find people who do want it, but if you have not deliberately formed the habit of prospecting for needs, regardless of wants, then unconsciously you have formed the habit of limiting your prospecting to people who want life insurance and therein lies the one and only real reason for lack of prospects.

As to calling habits, unless you have deliberately formed the habit of calling on people who are able to buy but unwilling to listen, then unconsciously you have formed the habit of calling on people who are willing to listen but unable to buy.

As to selling habits, unless you have deliberately formed the habit of calling on prospects determined to make them see their reasons for buying life insurance, then unconsciously you have formed the habit of calling on prospects in a state of mind in which you are willing to let them make you see their reasons for not buying it.

As to working habits, if you will take care of the other three groups, the working habits will generally take care of themselves because under working habits are included study and preparation, organization of time and efforts, records, analyses, etc. Certainly you're not going to take the trouble to learn interest-arousing approaches and sales talks unless you're going to use them. You're not going to plan your day's work when you know in your heart that you're not going to carry out your plans. And you're certainly not going to keep an honest record of things you haven't done or of results you haven't achieved. So let's not worry so much about the fourth group of success habits, for if you are taking care of the first three groups, most of the working habits will take care of themselves and you'll be able to afford a secretary to take care of the rest of them for you.

But before you decide to adopt these success habits, let me warn you of the importance of habit to your decision. I have attended many sales meetings and sales congresses during the past ten years and have often wondered why, in spite of the fact that there is so much good in them, so many men seem to get so little lasting good out of them. Perhaps you have attended sales meetings in the past and have left determined to do the things that would make you successful or more successful only to find your decision or determination waning at just the time when it should be put into effect or practice.
Here's the answer. Any resolution or decision you make is simply a promise to yourself, which isn't worth a tinker's dam unless you have formed the habit of making it and keeping it. And you won't form the habit of making it and keeping it unless right at the start you link it with a definite purpose that can be accomplished by keeping it. In other words, any resolution or decision you make today has to be made again tomorrow, and the next day, and the next, and the next, and so on. And it not only has to be made each day, but it has to be kept each day, for if you miss one day in the making or keeping of it, you've got to go back and begin all over again. But if you continue the process of making it each morning and keeping it each day, you will finally wake up some morning a different man in a different world, and you will wonder what has happened to you and the world you used to live in.

Here's what has happened. Your resolution or decision has become a habit and you don't have to make it on this particular morning. And the reason for your seeming like a different man living in a different world lies in the fact that for the first time in your life, you have become master of yourself and master of your likes and dislikes by surrendering to your purpose in life. That is why behind every success there must be a purpose and that is what makes purpose so important to your future. For in the last analysis, your future is not going to depend on economic conditions or outside influences of circumstances over which you have no control. Your future is going to depend on your purpose in life. So let's talk about purpose.

First of all, your purpose must be practical and not visionary. Some time ago, I talked with a man who thought he had a purpose which was more important to him than income. He was interested in the sufferings of his fellow man, and he wanted to be placed in a position to alleviate that suffering. But when he analyzed his real feeling, we discovered, and he admitted it, that what he really wanted was a real nice job dispensing charity with other people's money and being well paid for it, along with the appreciation and feeling of importance that would naturally go with such a job.
But in making your purpose practical, be careful not to make it logical. Make it a purpose of the sentimental or emotional type. Remember needs are logical while wants and desires are sentimental and emotional. Your needs will push you just so far, but when your needs are satisfied, they will stop pushing you. If, however, your purpose is in terms of wants and desires, then your wants and desires will keep pushing you long after your needs are satisfied and until your wants and desires are fulfilled.

Recently I was talking with a young man who long ago discovered the common denominator of success without identifying his discovery. He had a definite purpose in life and it was definitely a sentimental or emotional purpose. He wanted his boy to go through college without having to work his way through as he had done. He wanted to avoid for his little girl the hardships which his own sister had had to face in her childhood. And he wanted his wife and the mother of his children to enjoy the luxuries and comforts, and even necessities, which had been denied his own mother. And he was willing to form the habit of doing things he didn't like to do in order to accomplish this purpose.
Not to discourage him, but rather to have him encourage me, I said to him, "Aren't you going a little too far with this thing? There's no logical reason why your son shouldn't be willing and able to work his way through college just as his father did. Of course he'll miss many of the things that you missed in your college life and he'll probably have heartaches and disappointments. But if he's any good, he'll come through in the end just as you did. And there's no logical reason why you should slave in order that your daughter may have things which your own sister wasn't able to have, or in order that your wife can enjoy comforts and luxuries that she wasn't used to before she married you."

He looked at me with rather a pitying look and said, "But Mr. Gray, there's no inspiration in logic. There's no courage in logic. There's not even happiness in logic. There's only satisfaction. The only place logic has in my life is in the realization that the more I am willing to do for my wife and children, the more I shall be able to do for myself."

Imagine, after hearing that story, you won't have to be told how to find your purpose or how to identify it or how to surrender to it. If it's a big purpose, you will be big in its accomplishment. If it's an unselfish purpose, you will be unselfish in accomplishing it.

And if it's an honest purpose, you will be honest and honorable in the accomplishment of it. But as long as you live, don't ever forget that while you may succeed beyond your fondest hopes and your greatest expectations, you will never succeed beyond the purpose to which you are willing to surrender. Furthermore, your surrender will not be complete until you have formed the habit of doing the things that failures don't like to do.

Sunday, October 20, 2019

Problems at scale




When you're working inside a single team, alignment isn't hard. You just know what others are doing and when you don't you just ask. It's not too hard.

When there are multiple teams, it becomes a bit trickier. Each team has their own direction. However, try to add partners and suppliers. Each with different motivations and incentives.


Think about it this way: 2 teams want to integrate. Half way through you find out that one team is building a bridge and the other is building a tunnel. WTF is a common reaction. The overall conclusion is that someone needs to take charge.

Then we come to the following common misconception:

Complete alignment - teams do whatever the leader says.
Complete autonomy - teams do whatever.

Alignment enables autonomy.

Image result for tightly aligned loosely coupled

There are multiple ingredients required to reach alignment at scale.

  1. Shared purpose
One wild question pops up: What are you working on and why?
Possible answers:
  • We're working on X because Sam said it's important.
  • We're done when Sam is OK with it.
or
  • We're working on X because we feel like it.
  • We're done when we don't feel like it anymore
First answers come from alignment and second from autonomy.

Alignments happen at different levels:
  1. x people are working on the same feature
  2. y teams are working on the same product
  3. z clusters work for the same company
To use the first ingredient correctly, all team members need to be part of the same chain of purpose:
  1. we're gathering wood
  2. we're creating a foundation
  • so that we can build a bridge
  • so that people can cross the river
  • so that we can connect the two villages
  • so that we can make life easier for everyone
  1. Transparency
One of the most important questions when aiming for transparency: Who needs what from whom and when?

You guessed it. It's about dependencies.

When you have a complete map of dependencies, you can detect early if you have dependency problems. If you have a centralized tool, you enabled decentralized behavior.

A high level alignment meeting is to talk about these dependencies: scrum of scrums.
  1. Tight feedback loops
Some say agile is like a homing missile.

Image result for homing missile



Single teams have short feedback loops:
  • unit tests
  • sprint reviews
  • daily standups
  • retrospectives
  • continuous integration and delivery
Multi team feedback loops are more elaborate:
  • cross team syncs
  • common retrospectives
  • whole product review
  • component integration on a scheduled basis
  • monthly or quarterly alignment events
    • demos - what have we accomplished from last time?
    • team boards
      • deliverables per sprint
      • risks
      • impact based objectives
The pattern remains the same. Plan monthly or quarterly together and release on demand.
  1. Clear priorities
It's clear that everyone has a lot to do, but not all of these todos have the same priority. It would help to split into impact levels. And then ask: If we could do just one of these 2 things, which one do we do and why?

Higher level priorities should inform lower level priorities. Stakeholder input makes it easier to decide what to work on. Teams are still responsible for figuring how to make the best use of their time.

If priorities are not clear, they end up being reviewed by executives and solved quickly. Remember, management is there to help.
  1. Organized learning
When teams learn together, everything can improve:
  • velocity
  • motivation
  • focus
  • quality
  • release capability
How does learning spread across teams? Through common lunches, cross team retrospectives and team member changes. Teams cannot be too busy for improvement.

If unstable teams mean chaos, too stable teams mean high efficiency, silos and slow organizational learning. Try a solution with a slow drop in efficiency but incorporate organizational learning.

Short recap: Alignment means teams have a shared purpose, are transparent, have short feedback loops, clear priorities and learn together.

Now, who puts the ingredients in? Leaders!



Sometimes we like to pretend we don't have leaders, that leaders are evil and self organization is best.

But, who enabled this self organization?




Call it what you want, but it's a leader's job:
  • to create a shared sense of accountability
  • create conditions that enable teams to align
  • ensure that decisions can be made
Leaders don't have to be a single person. They can be part of a core team.

This is a short introduction to agile at scale. Who enables it, how it works and what ingredients it needs not to fail.





Friday, October 18, 2019

Executives - why do they always ask the hard questions?

You know executives are in a room when most of the people shut up. For an outside observer they seem to bring no value in the meeting.

Image result for executives cartoon

This is the perfect picture of a meeting where executives are in the room.

People are afraid. Why are people afraid of management? Management is there to help. Always. Remember "with great power comes great responsibility"? They are Spiderman.

Some have earned their title, some have been bitten by a spider, but most of them are there to help.

Executives don't care about you, as an individual. They don't know you. They only care about results.
If you're ever in a room with executives keep 2 things in mind:
  1. you know more than them about the topic
  2. they are there to help, but you need to show them the problem
Of course executives are not superhuman. Of course you absolutely know more about your projects problems and complexities. But when you need to report to an executive, you have to understand that they need simple things like:
  1. where are we now?
  2. what is the clear message that you want them to know?
  3. what are the problems?
  4. what are the solutions to the problems?
As a reporter, you need to paint a clear picture of the current state of affairs.
Let me say that again: 
  • paint a clear picture
  • to someone who does not have your context
  • wants to help
That translates in:
  • cut the bullshit and fancy words
  • don't waste time on slides
  • if you do slides, have a clear message that you want to send, on each slide
Be aware that if your message is not clear enough (this is executive fuel) the hard questions will start. Why? Because the executive's actually trying to understand your message. If you don't do a good job there, it's entirely on you. 

I think that most people go into executive meetings thinking that they actually know more than the people reporting. They don't. They cannot. They will not. This is your job. But it's also your job to be transparent and clear in messaging. 

I actually learned this the hard way. One executive asked me only once: What is the message i should get from this slide? Then it hit me. Everything made sense. The hard questions turn into the simple questions.

Executive questions are simple: your message needs to make sense to them. But there's one caveat: small steps. Small understandings. They don't want the story from A-Z. They want you to paint them a picture from A-B then from B-C and so on.

If you encounter a hard question from an executive, they're not being evil. they just don't understand. Make it easy for them to understand your message.

I think the redundancy above made it clear for you.

Whenever an executive asks questions it's because it does not make sense to them. Your message had missing pieces. If you somehow get here, be prepared to give short and simple answers. Don't be elaborate. You hate that, they also hate that. Also, it's ok to say you don't know, but make sure to add that you're getting back with an answer or ask somebody in the room if they are more knowledgable on the topic. Give short answers only if you know the answer.

Another thing that you might encounter is finding a problem without an owner, with an executive in the room. That's ok. Be sure to always take the task and promise with a date and your name to get it done. Never stay silent like you saw a ghost. Problems are everywhere, it's also shameful when an executive finds it before you. That's ok, take that action item and move forward. Next time, be sure to have less loose ends, but don't sacrifice transparency. They can only fix and prioritize what they know. 

That's not executives help and fix problems. They use their leverage to set certain priorities to correct course.

If the problem is known and the meeting is to raise it, also make sure the solution makes sense. A-B not A-Z. If the solution is not complete, raise that. Raise the impediments and set the stage for discussion of a specific problem in your solution until everyone has the same understanding. Then ask for help.

Always put a focus on the problem and don't fall in love with your solution. Problem understanding is critical when you need management help.

Executives are normal people who have leverage to steer and solve problems. Go to them. Raise your problems, own your problems and execute solutions like a motherfucker.

Wednesday, October 16, 2019

How important is alignment between people and teams?

What is alignment?

This is a simple question with a simple answer. Alignment between people and teams means having the same understanding of the current state of the affairs, strategy and goals, at the same time.

It's not hard. Think about it like this. You schedule a dinner with your friend. The moment you find out you cannot join, you send a message to reschedule. That's it. Both parties have the same information at the same time.

What does this imply?
  1. As soon as information changes, it has to be broadcast to all the affected parties.
  2. Information change means change of plans for both parties. 
  3. Common planning has to happen again.
Simple, right? 

What if the information change fails to reach all parties as soon as possible? Waste happens. The later the information arrives to the affected parties, the more waste gets created. Besides waste, there can also be actions taken that are not easily reversible. Think about if your friend is driving to the restaurant already because you failed to inform him about the change you know about 2 hours ago. You can add frustration to the effects. The last effect is the impossibility to create new plans for your friend on that night. Last but not least, you might be perceived as not transparent.

So, if we fail to broadcast information as soon as we know about it this is the effect we're accountable for:
  1. waste
  2. non-reversible actions
  3. frustration
  4. lack of transparency
I'm no saying this won't happen if you broadcast the new information immediately. You also might get new information too late. But if you continue with the late delivery of information, you're becoming part of the problem.

There is one caveat to information broadcasting. The dinner example may not be the best. When sharing new information you, as the informer, have to make sure the other party truly understands the new information. Is it crucial to do so because if you fail in making yourself understood, different information ends up being broadcast to others(this is something you cannot control). You can only control your part. So, make sure there is no misunderstanding. Avoid a snowball of misinformation. If the case is more complex, offer your support to clarify it to others. 

I chose this topic because it's something i'm facing every day. The root cause of this might be culture. Working with non-autonomous teams is another root cause. If i dig into this topic more i find something else. Experts make confident decisions. Experts are informed. They have experiences change and they know that working in technology means a lot of change. Inexperienced individuals expect clarity in tasks. Experts expect clarity in goals.

Image result for management agile levels autonomous teams

Show them the goal and get out of the way. If you're google, let them pick the goal for themselves.

Sunday, March 24, 2019

What is customer development?

Customer development is the process of discovering problems experienced by potential customers and solving them. If this process is implemented correctly, products will create value for customers due to the exhaustive research and testing and go on to be successful.

Brilliant entrepreneurs don't really start out with concrete goals, but they constantly assess how to get their vision into peoples hands and reacting creatively.
It's the age where advanced technology is "easily" accessible to most organizations, only the ones that learn to quickly adapt to change survive. Doesn't matter if it's a startup or a well established enterprise.

Products should not get developed or launched until they're assured to have a customer base ready and waiting. The entrepreneur's role is not to lead customers to the problem. The less leading while hearing your problem getting mentioned, the more validation you get.

The customer development model has 4 parts:

Customer discovery
Customer validation
Customer creation
Company building

The goal is not to simply understand customer behavior, but to change it and build a sustainable business around that change. People usually try to guess what’s good for the user and they’re mostly wrong, no matter how good they are. Entrepreneurs should learn what their customers really need, and use that knowledge to build what they’re willing to pay for.

While it’s very uncomfortable to ask questions that prove your assumptions wrong, it’s essential for success. Regarding what I said earlier, if you’re initial assumptions are proven wrong you have to adapt and change your mind and roadmap. Always remember that you’re not Steve Jobs. Nobody is. And most likely you’re not building computers, but software. You won’t be able to predict customer development and you have no idea what you’re going to learn until you start. The ability to adapt as you uncover new information is priceless.

Most likely your business model is loaded with opinions, assumptions and guesses (along with hope and vision), that’s why you need to get out of the building as validate each of those guesses in the model. I cannot stress this enough.

From your first customer interview, you will learn that the context of the problem you’re trying to solve is much broader than you and your team imagined. Customers make the product successful. If your solution will solve their problem so well, they will become your sales team. If the thought of not being able to use your solution will make them very disappointed (>40%), the you have product-market fit.

Customer development is a way to reduce your business risk by challenging assumptions about who the customers are, what they need, and why/how they buy. The risk of not doing customer development is building something no one wants to buy. Everything in customer development is about testing hypotheses. Think about it this way: if you’re wrong, you want to find out fast, right? If you can’t find customers or they contradict your guesses, you pivot the product or the market (more nicely put - you modify your hypotheses).

Customer development really brings you a deeper picture of your customer and the competition, the opportunity to uncover new ways for differentiation and you’ll definitely reduce the amount of product you need to build.

It’s easy to start. Just take your current assumptions and a customer segment and go have a conversation. It’s not really important if you’re right. Each time you’re wrong, it will help you make better guesses next time. Have narrow hypotheses to focus and progress faster. If the scope is broad, you end up doing a lot of interviews with no actionable data. Demographics aren’t customers.
In the beginning you should look for the most enthusiastic and passionate potential customers. If you don’t find them now, how were you planning on finding them after you built the product?

Steve Blank calls them “early evangelists” - people who are willing to take a risk on your unproven and unfinished product.

I’ll detail each of the steps in future posts, but what you should remember is to start with:
  1. Identify a need
  2. Think of potential solutions
  3. Validate assumptions
  4. Deliver an MVP
  5. Repeat (constantly reevaluate your solution)

You need to make it clear to your team, stakeholders or cofounders:
  1. Who your customers are
  2. What problems and pains they have
  3. What is their current behavior
  4. What are they willing to pay for
  5. How to build a solution that works with how your customer buys and uses

And lastly, customer development is not product development. Product development is the process of building a new product or service and bring it to market. Product development equals delivery. Customer development is finding the truth on what to build and for whom.

Contact us: engineering@the-lean-startup.com for customer development


Saturday, March 23, 2019

Product manager responsibilities

There are multiple responsibilities to a product manager. I'm going to go through some of them because the ideal product manager is a T shaped individual, with deep knowledge in one field and multiple experiences in other fields. An ideal product manager should have experienced every role in the PDLC (Product development life cycle).

Strategy and vision


A first key responsibility is about strategy. Strategy needs to be clearly articulated to the product team so they understand the intent behind the new product or iteration. The "why" needs to be supported with data and results from the customer development phase.

The strategy must also make mid or long term sense to the business goals of the company.

To be more specific, the product manager needs to make sure stakeholders, the product team, sales and marketing understands what is going to be built, what the customer value is, what pain is it solving and who the product is for.

Roadmap


After the "what" is articulated and support is granted (I always think that the first responsibility is a pitch to secure funding and support. This second responsibility is having a plan that makes sense) and vision is set, it's time to create an execution plan. This will include high level features and experience mapping for the customer journey to solving their pain.

After the high level features have been prioritized, the team tries their best to estimate them so a timeline can be created. This timeline will usually be rejected by stakeholders :). In a truly agile environment the roadmap will change and the team should always be working on the most important customer value it can deliver. In a waterfall environment, specifications change slowly.

Tactical leadership


The product manager is responsible for the groomed backlog, granular features and user stories and making sure the team is not stuck and requirements are clear on what needs to be built. The product manager is the glue between design, engineering and product and he/she has to ensure that there are no gaps and the team is able to deliver on expectations.

It's also important to deliver a minimum viable product (MVP) at first so the product manager can start asking for feedback from initial customers, stakeholders etc.

Launch and iteration releases


After the product has passes quality control, the value proposition has been validated by test customers, the product or feature is launched. This is where the product manager needs to start gathering quantitative feedback and decide what goes in the next iteration. Basically there will be a lot of decisions on what not to build.

If things go at least half of how they're expected to go, the product usually needs to enter a growth phase, reach maturity and a stabilization phase (months to years).

Contact us: engineering@the-lean-startup.com

Sunday, March 17, 2019

What is product management?

Product management is the process where a product owner/manager translates customer pains into solution requirements while making sure the solution is profitable to their business. The product manager needs to bring clarity to their team.

So I started arguing that product management is a process. While the product manager has multiple jobs to do (will detail on this later) product management is the process where there is a clear communication path from the validated customer pain to each granular task that goes into the backlog and eventually gets shipped back to the customer. If we live in an alternate universe, things stop here. But usually customers come with feedback and lots of it.

The product management process

The ideal process is when features or product ideas come form a validated market need (there are other cases, but I won't cover them in this post).
A validated market need is when a customer segment has an important problem and "hacked" a solution together to fix it. Hacking a solution can mean using pen and paper for documenting disease progress (non-digital medical journal) or hailing in the street on a rainy day for a taxi - in Uber's case.

In the customer interview process (requires getting out of the building - there are no facts in the building, only opinions), customers should not be asked about solutions or even mentioning your idea to the solution. In this part of the process, product managers should talk 2% and listen 98%. Try to get the potential customer to explain in his or her words the pain and the experience facing doing a particular task. And listen, I cannot stress this enough. Now, repeat this process until you get repetitive answers.

Go back to the team and map that data and create a story map. Tell the customer story and make personas. Feature decisions should be data driven, not opinion given, although sometimes it helps to have an expert on board to confirm certain paths. But usually the customer data is the most valuable resource you have at this point. No usage metrics, churn rates etc. Just raw data that needs to be empathized into a solution.

After you figured out how to clearly state the problem and the customer story the product manager needs to prioritize. What is the most important problem that the potential customer would highly appreciate our product to solve? Does it make sense to the business? Would the customer pay for the solution? How much would the customer pay for it?

The product manager prioritized some problems to solve based on his "feel" from empathizing with the customer, data, their business, the market, the current competitors (competitors can be pen and paper - not every digital product is better than pen and paper because in some markets there is a restrain from adopting a digital solution over an analogue one) etc.

After the prioritization, user stories need to be created. A user story is just a part of the feature that is expressed somehow in non-technical customer language. As an example, these are user story examples:

  • as a customer I want to login with Facebook
  • as a customer I want to add a reminder
  • as a customer I want to have home/work suggestions when starting my navigation system
Let's take the last one as a thought process. I don't believe any customer said 10 years ago that this is what they want to see when their navigation system boots up but a product manager decided that these are the 2 most important locations to navigate in a customer persona. The customer would want to navigate to work and back home. In the interview customers might have said that they use the car to get to work, grocery shopping and taking their kids home from school. This is customer empathy.

Getting back to the user stories. After they were created, they are tackled by the development team, going through CI processes, tested by QA, validated by the product manager and presented to the stakeholders. In each of these steps there is feedback and fixes are in place (again, prioritized). After a significant and also minimal amount of features are build, tested and validated, the team has a working prototype or minimal viable product. 

The product manager takes this product back to some of the initial customers in the interview process and gets it in their hands: What do you think of this solution? Watch the customer interact with your solution, just watch. They're going to have questions, not find things and give feedback. 

Take this feedback back to the team. Rinse and repeat.

This should usually go to the next level when you make your initial customers love you and get to product market fit.

This was a shot presentation of the product management process. There are multiple things that go wrong and products that fail. But you should always remember: talk to your f****** customers! Assumption is the mother of most fuckups. 😵

Saturday, March 16, 2019

What is product-market fit?

There are many definitions, but you can basically "feel" product-market fit when the market pulls product out of the startup (as defined by Marc Andreessen in the only thing that matters). Customers are banging on your door to get the product and this is your first API performance/load test - usage is growing as fast as you can add more servers.

Your product does not have to be great. it has to barely work and solve the market problem. The market does not care about how good the team is either, as long as it can produce a satisfactory product.

There is only one way to strive for this holy grail that is called product-market fit. Doing customer development. I always imagine the market as one circle, and the product as another. Finding product-market fit is a process in which you either move the product to overlap the market or vice-versa. You may pivot (change product or market) until you have fit. 

You can always feel when this isn't happening: usage isn't growing, page views are meh, sales cycle takes too long, deals never close and word of mouth isn't spreading. Basically customers, aren't quite getting value out of the product. Imagine the overlapping circles again: it's like your product circle is satisfying 1% of the wanted market circle and the other 99% are users in other markets that you're trying to get on board. They don't really see it because you're not solving their pain. The hard part is to finding more of the 1% types of customers. Again - customer development.

There's something more to say about this holy grail. I think that products that hit this landmark in their iteration also get an advantage from the market - if they satisfy 10 users so well, these users might begin to share their positive experiences with others. All of a sudden, customers become your sales people.

There is also a core metric to test if you're unsure about this achievement. Ask customers a single survey question: "How would you feel if you could no longer use this product?" If >40% respond with "very disappointed" - you need to start scaling. If the percentage is lower, continue doing customer development and iteration until you hit the 40% benchmark.

I think you can also measure the fit of the product when a large percentage of users get to the "aha moment" - it's like meeting an attractive person and realising you're attracted to her/him. There's no misunderstanding or uncertainty about it. Replace the person with a product and the "aha moment" is the moment a user realises the value of a product.


A product manager has to bring clarity to their team

Satya Nadella, the CEO of Microsoft, argues that clarity is a trait he's looking for in new hires. I'm not taking things out of context, because he also said that he looks for energy in new hires, but that's harder to define. You can take a look at this 2-minute video interview:


Returning to the product manager, I think clarity is something vague at this point and needs to be split. Whenever you have a new product manager or owner, he needs to bring four major critical contributions to their team. The product manager needs to have deep knowledge:

  1. in the customer segments
  2. in the data
  3. of your business and its stakeholders
  4. of the market and industry

Customer segments


Clarity in the customer segments is not just having complete profiles but having the ability to empathize with these customers. Every decision that goes into the product must bring value to the customer - this is not just a fancy sentence - anything that goes into the sprint from the backlog has to actually be something that solves a known product problem or a new important customer problem. 

Regarding the enforcement to the sprint I made above, keep in mind two inconvenient truths that cause failed product efforts:

  1. at least half of our ideas are just not going to work - customers ultimately won't use it (which is why you need customer validation and customer discovery early in the process)
  2. it takes several iterations to implement an idea that delivers necessary business value (every agile product ever except car companies with unconnected cars) - you can argue that all cars are basically the same (for now) and any car solves more or less the same customer problem - taking you from A to B (some are self-driving, some have leather seats, some are fast etc).

Data-driven decisions and stakeholder management


I'd make the statement that any product manager that has a successful product or is building one that's going to survive, has to be data-driven. Typical roadmaps nowadays are the root cause of waste and failed efforts in product organizations. The motivation: that it's easy to create processes that govern how you create products and bring innovation. Yes. Some stakeholders think that innovation can be solved with a fixed process. 

This type of organization needs to wean off typical roadmaps and focus on business outcomes, providing stakeholders visibility so that they know your team is working on important items and eventually make high-integrity commitments when critical delivery dates are needed. Part of this is managing stakeholder expectations and engaging them early in the product discovery process with (ideally) high-fidelity prototypes. To manage stakeholder expectations, a product manager needs to bring clarity to the table and also understand the stakeholder's context.

Being data-driven also means that you, the product manager, gets to decide what is built. If you get backlash, bringing customer data to the table, needs to be the only source of truth. But be careful, the decisions, have to be compliant with the long term vision of the product and also make business sense.

Market and industry knowledge


The product manager needs to be aware of the organization concerns and also about the market conditions. She should have knowledge of valuable business models and consciously apply a specific model when required. 

Your team needs to be aware that the product meets the needs of a specific market. Market knowledge also means being aware of the competition and that is the differentiator to your product. Depending on your customer segments, the product manager can also assume the size of the market based on customer interviews and quantitative numbers extracted from that data. When trying to figure out the market size and condition, the product manager also needs to be in sync with marketing, sales, customer success, finance, legal, BD, security etc, before making market statements. 

Again, talking with different people inside the business and ecosystem can get the product manager closer to the market truth, limits and movement.

Product managers need to bring clarity

While the entire team is responsible for product success, only the product manager is responsible for product failure. The argumentation here is very simple: the product manager had all the tools, people, team, data and access to key people. If the product is a failure, the decisions were wrong and the product manager made them. The product did not solve an important problem for the customers in the market he researched.

Possible reasons for bad decisions: 
  • untested assumptions
  • no real empathy for the customer
  • company constraints
  • confirmation bias
  • wrong direction
  • wrong timing
  • the wrong market
  • the wrong problem solved
  • low-quality product
  • failure to satisfy early adopters
  • failure to listen to customers
  • scaling too early

Make 10 customers love your product. If you manage that, you'll be successful. 

What is customer discovery? (short version)

This is the first step in the customer development life-cycle.


You need to find who the customers for your product are and whether the problem you believe you are solving is really important to them. Leaving guesswork behind, you should get out of the building to learn what the high-value customer pains are, how your product solves these pains and who specifically is your customer - has the power to make or influence the buying decision - and user - who actually will end up using the product on a repeated basis.

Keep in mind, that this step is not about collecting feature lists from prospective customers, and neither tunning a lot of focus groups. If you're a startup, the founders define the first product. The job of the customer discovery team is to see whether there are customers and a market for that vision.

In this particular step of the process, you should be in the field, listening and discovering how your customers work and what their key problems are.

As action points: you need to dig for negative feedback.

The goal of customer discovery is to turn the founders' initial hypothesis about their market and customers into facts.


What you should know before your team starts building a new product



There are some questions you and your team should answer before starting out to build a product:


  1. Is there a group of customers who would buy this product?
  2. Is this a significant pain point for them, or a minor one?
  3. Are people really excited about an idea like this or is the response pretty meh?
  4. How big is this group of customers potentially?
  5. Is there a change or a tweak or a full scale revision to this idea that would radically increase the number of customers?
  6. What price might customers be willing to pay?
  7. What solutions are customers currently using to solve this problem? Is this solution pretty good or pretty bad? How receptive are people to the idea of a better solution?
  8. How much are people currently paying for this alternative solution?
  9. How would you reach these customers? Is there a place where they get together? One or more websites they all read? Conventions they all attend?
  10. Would these people tell their friends about your idea, or not? (this is a measure of word-of-mouth resonance)

These are 10 basic questions that need a lot of effort to be answered. But the effort needed is way smaller than the pain of building a solution for a problem nobody has.

First thing to do is get out of the building. There are no facts in the building.