Luke Szyrmer

Disproved: Most successful products are launched exactly the way they are envisioned

December 11, 2019 by LaunchTomorrow 1 Comment

Icarus and his father Daedalus, the architect of the Labirynth, attempt to escape by air from Crete. Daedalus had become a political refugee. He had helped Theseus, an enemy, break into the Labirynth to kill the Minotaur.

Icarus falls, assuming the plan so good he doesn’t need to watch himself implement it

Daedalus then constructed wings from feathers and wax. Icarus’ father warns him first of complacency and then of hubris. Daedalus asked that Icarus fly neither too low nor too high. The sea’s dampness could clog his wings. The sun’s heat could melt the wax. Icarus ultimately ignored his father’s latter instruction. He flew too close to the sun. When the wax melted, Icarus tumbled out of the sky, fell into the sea, and drowned.

How is this relevant when launching new products?

Entrepreneurs have a strong sense of vision, particularly when creating something new and magical like the wings in the legend above. That’s why we love them. Working alone or as a small team, they execute. They see something no one else does, and they pursue it relentlessly, until it happens. In one form or another.

He dreamed about a stargazing and slowly getting there. — Photographer: Rahul Bhosale | Source: Unsplash

Conversely, corporate innovators often have to plan a lot up front, to align across multiple departments and stakeholders. Which means that detailed planning results from significant negotiations. And that any change often requires re-negotiation. But there is a great deal of vision and planning required to create something out of nothing.

These two scenarios have more in common with one another. Vision and planning is crucial, but having too much of an attachment to any plan is counterproductive.

Believing too much in the initial plan is clingy (and can feel unproductive)

For years, I was curious about whether there was any data to back that up. If you want to create a successful product, usually you want high growth as an ultimate metric of success. Recently, I found that data point.

In The Origin and Evolution of New Businesses, professor Amar Bhide of Harvard interviewed the founders of an entire year’s-worth of Inc 500 companies in the late 1980s, a ranking of high growth startups. This is independent of sectors and also not influenced by any of the more recent lean startup/small batch thinking. At the time, most startups needed to raise a significant amount of money to launch anything new. From a funding & risk perspective, the success criteria were close to that of corporate product development today.

Bhide reported that approximately 2/3 of the founders he spoke to pivoted away from their original concept:

More than one third of the Inc 500 founders we interviewed significantly altered their initial concepts, and another third reported moderate changes.

The majority of the founders shifted away from their original vision. Was it out of necessity? Or is being both willing and able to adapt is actually a requirement for new product success. One third of the founders were lucky to have guessed exactly what their customers wanted. But most needed to adapt and pivot to the best possible business model.

Plans are worthless but planning is everything –Eisenhower

In other words, the most helpful mindset & approach is to:

assume that you will be wrong about something when launching a new product
make sure you have the option to pivot
often, this happens once you collect data that challenges your assumptions…so collect data first!

This is how innovators work. This is also how “search” for a new business model differs from executing a known business model and aiming for efficiencies only.

This post is part of my “7 Lies of Innovation” email course. Click here to sign up if you’d like to know when the common wisdom around innovation doesn’t actually hold up in the data.

<< Help Yo' Friends

4 approaches to track your assumptions, when starting to work on a new business idea

October 23, 2019 by LaunchTomorrow 1 Comment

In The Origin and Evolution of New Businesses, Amar Bhide reported that 2/3 of the Inc 500 company founders he interviews pivoted away from their original concept:

More that one third of the Inc 500 founders we interviewed significantly altered their initial concepts, and another third reported moderate changes.

In other words, it’s best to assume that you will be wrong about something when launching a new product, and make sure you have the option to pivot. Usually this happens once you collect data or information that challenges your assumptions.

In practice, assumptions are beliefs that you have which must be true for your new business venture to work. Usually, when you are starting out you make hundreds of assumptions, simply to get going. To start making progress despite the uncertainty.

Identifying the riskiest assumptions is an excellent use of your time up front. Much better than building technology (which is where almost everyone wants to start). All that said, it doesn’t really matter how you keep track of this or think about it. Just that you actually do it.

Economic impact of risk factors

In How to Measure Anything, Douglass Hubbard analyzed variables that had potential economic impact on the success of an IT project in established companies. By economic impact, these are random occurrences which could happen with significant negative variability. They would be realized as an unexpected cost. These risk factors included things like: initial development costs, adoption rate, productivity improvement, revenue growth and so on.

He evaluated the usefulness of all of these variables and had the following observations:

The 60 or more major risk/return analyses I’ve done in the past 16 years consisted of a total of over 4,000 individual variables, or an average of a little over 60 variables per model. Of those, a little over 120 (about 2 per model) required further measurement according to the information value calculation.

This mirrors the pattern I’ve seen when working with startups and established companies launching new products. Here’s the pattern with respect to assumptions:

Most of assumptions are completely trivial.
A handful are important.
And a few might be absolutely critical to getting your business off the ground.

In short, there are hundreds of potential metrics and numbers you could track. Most of them are irrelevant. Also there is a cost to checking/monitoring them, so in fact it’s better not to check and monitor them.

Approach 1: Tracking risk factors in spreadsheet

For example, when you do financial modelling for a traditional business plan, you have one tab that lists out the assumptions you’re making and feeding into the financial model.

You have to make some kind of revenue projections. What do you base that on? Instead of just operating in a vacuum, you can proactively try to figure out what assumptions you’re making, and then go run some experiments to validate whether these assumptions are true.

Examples of financial assumptions in a business plan | source: immigratemanitoba.com

Well, in the case of a new product, you actually want to look at assumptions a bit wider than just the financial ones. Revenues and costs are simply easy to map out, because they’re very visible. You see money coming in or leaving. But there are a number of other assumptions which will make or break you.

In short it’s fine to use a spreadsheet, but go beyond just financial modelling. There are a lot of other assumptions you’re likely to be making–which can have a material impact your venture.

Approach 2: Business Modelling using a canvas tool

To wit, consider that revenues and costs are just 2 of 9 boxes on Strategyzer’s business model canvas:

If you don’t have clear customer segments and channels to acquire them, the financial assumptions are arguably irrelevant. In practice, you make assumptions with respect to all 9 boxes in your entire business model canvas. If you aren’t deliberate, you will make them implicitly. Which could be a problem…

Revenue is easy to explain, simply because you need revenue projections for a financial forecast. But in fact, all nine boxes are based on assumptions that you’d ideally make explicit and figure out if they’re true as you execute on your idea.

Looking across the entire business model, one assumption in any of those boxes can kill your entire new product. This is exactly why new product development is different than running an existing business. In an existing business, the assumptions underlying the business are proven. And you are just looking to optimize what’s already working. Here, you’re potentially starting from scratch. If any of these critical assumptions are wrong, then your business model and your plan won’t work. Or won’t work very well, if they’re less critical.

Approach 3: Going even wider doesn’t make sense at an early stage

You can look even wider at longer term trends or risks that might affect you. But for an organization that doesn’t exist yet, it’s just not a good use of time if you want to get something off the ground.

Let’s zoom back to the year 2001, the year of the dot com crash. The basic technology was already developed for web consumer companies. And it seemed like every idea ever had already been tried. I mean, even pets.com had a go. Who would have thought that you’d need to buy pet food and pet toys via a San Francisco based e-commerce entity? From a entrepreneurship standpoint, the early gold rush of putting everything which existed online had seemingly ended. And yet focussing on that fact would have been unproductive.

So while you don’t need to go through hundreds of variables and studies and groupings, focussing on a limited number of categories for your business, you get most of the benefit.

Approach 4: The most important boxes according to published research

If you want a pointer to focus certain areas, consider this observation by Tedd Ladd in Harvard Business Review:

In my research with cleantech entrepreneurs, I found that teams that focused their testing on the triumvirate of target customer segment, value proposition, and channel performed twice as well as teams that did not spend much attention on those three categories.

Notice that this isn’t “revenues and costs” as per the traditional approach. In fact, this is the best place to spend your time.

Strategyzer was clever enough to create a “mini-canvas” that helps focus attention on those boxes + the revenue box. I don’t think it’s available for download, but that was the gist of it.

It doesn’t matter where you keep track of assumptions as long as you do

All in all, it doesn’t really matter what tooling you use to keep track of this stuff. What matters is that you think it through, keep track of your thought process, finally gather data to prove & disprove your chosen key assumptions. If there are 2 variables which matter, even intuitively, then you’ll be in much better shape if you at least try to check them. If you can’t do it quantitatively, by all means do user interviews.

My favorite tool to get start is my own Hero Canvas. Because I work with a lot of technical people and inventors, they have the technology side nailed. But they haven’t even thought through who might be interested in their product. It maps to the customer box in the Strategyzer Busisness Model Canvas. It’s also one of the three Ladd seemed to suggest that are worth prioritizing. And ultimately, you’ll only have a business if you can convince prospects to give your product a try.

Key takeaways

You will make hundreds of assumptions to get started on your new business.
Most of them will be irrelevant. A few of them will be absolutely critical. Think through what they are.
Then document this and figure out how you can gather some data to validate those assumptions.

<< Help Yo' Friends

Why estimating cognitive effort simplifies knowledge work

October 9, 2019 by LaunchTomorrow Leave a Comment

“There were only an estimated two to five thousand humans alive in Africa sixty thousand years ago. We were literally a species on the brink of extinction! And some scientists believe (from studies of carbon-dated cave art, archaeological sites, and human skeletons) that the group that crossed the Red Sea to begin the great migration was a mere one hundred fifty. Only the most innovative survived, carrying with them problem-solving traits that would eventually give rise to our incredible imagination and creativity.” –Marc Sisson

Imagination fed into our uniquely human ability to cooperate flexibly in large numbers. So fast forward to today. Our most valuable and exciting work, particularly in the context of innovation, still relies on our ability to imagine what needs to be done, start, and continuously course correct.

In this case, we’re using imagination to structure and agree how work needs to happen, and to map that to a subjective estimate of effort.

First, we imagine what needs to be built, why it needs to be built, and how it needs to work. Then, we subdivide the big overall vision into lots of little pieces, and divvy it up among a group of people who go execute on the vision. Before they do that, though, these people imagine, analyze, and discuss doing the work involved on each specific piece of the overall vision. They all need to agree how much effort it will take to complete that task. If there are differences of opinion, they should be ironed out up front.

If done successfully, this generate full buy-in and alignment from everyone involved. Even if the end product isn’t a physical thing, this approach works. The benefits of trusting people and harnessing all their energy and imagination far outweigh the inherent risks. It’s already done by tens of thousands of teams around the world already in various digital industries including software.

Relative Cognitive Effort is what we’re imagining.

The key number that is used for tracking this is a measure of how much “cognitive effort” was completed over a predetermined unit of time. Agile and scrum use the concept of a story instead of tasks, in order to help describe complex needs in a narrative form if needed. Usually this includes elements such as: user problem, what’s missing, acceptance criteria for the solution required. Therefore, the unit of measure for the cognitive effort expected to complete a story is called a story point.

Each story is sized in terms of story points. Story points themselves are quite abstract. They relate to the relative complexity of each item. If this task more complex than that one, then it should have more story points. Story points primarily refer to how difficult the team expects a specific task to be.

For example, it’s more precise to track the number of story points completed in the last 2 weeks, than just the raw number of stories completed. As stories can be of different sizes.

Now it’s time for a few disclaimers…

1. Story points are not measures of developer time required.

Cognitive complexity isn’t necessarily the same thing as how time consuming it will be to achieve. For example, a complex story may require a lot of thought to get right, but once you figure out how to do it, it can be a few minor changes in the codebase. Or it could be a relatively simple change that need to be done many times over, which in and of itself increases potential complexity and risk of side effects.

The main purpose of story points is to help communicate–up front–how much effort a given task will require. To have meaning for the team, it should be generated by the team who will actually be doing the work. These estimates can then be used by non-technical decisionmakers to prioritize, order, and plan work accordingly. They can then take into account the amount of effort and trade it off with expected business value for each particular story.

2. Story points related to time are a lagging indicator for team performance.

The key, though, is that story points shouldn’t be derived as 1 story point = half day, so this item will be 3 story points because I expect it will take 1.5 days. This type of analysis can only be done after the fact, and related to entire timeboxes like a 2 week period. Instead, the team should be comparing the story they are estimating to other stories already estimated on the backlog:

Do you think it will be bigger than story X123? Or smaller?
What about X124?

The team needs to get together regularly and estimate the relative size of each story, compared to every other story.

This generates a lot of discussion. It takes time. And therefore estimation itself has a very real cost. Some technical people view it as a distraction from “doing the work”. Rightly so.

3. Story Points assume you fix all bugs & address problems as you discover them.

Only new functionality has a story point value associated. This means that you are incentivized to creating new functionality. While discovering and fixing problems takes up time, it doesn’t contribute to the final feature set upon release. Or the value a user will get from the product.

Anything that is a bug or a problem with existing code needs to be logged and addressed as soon as possible, ideally before any new functionality is started, to be certain that anything “done” (where the story points have been credited) is actually done. If you don’t do this, then you will have a lot of story points completed, but you won’t be able to release the product because of the amount of bugs you know about. What’s worse, bugfixing can drag on and on for months, if you delay this until the end. It’s highly unpredictable how long it will take a team to fix all bugs, as each bug can take a few minutes or a few weeks. If you fix bugs immediately, you have a much higher chance of fixing them quickly, as the work is still fresh in the team’s collective memory.

Fixing bugs as soon as they’re discovered is a pretty high bar in terms of team discipline. And a lot will depend on the organizational context where the work happens. Is it really ok to invest 40% more time to deliver stories with all unit testing embedded, and deliver less features that we’re more confident in? Or is the release date more important?

4. One team’s trash is another team’s treasure.

Finally, it’s worth noting that story points themselves will always be team-specific. In other words, a “3” in one team won’t necessarily be equal to a “3” in another team. Each team have their own relative strengths, levels of experience with different technologies, and levels of understanding how to approach a particular technical problem.

Moreover, there are lots of factors which can affect both estimates and comparability. It wouldn’t make sense to compare the story point estimates of a team working on an established legacy code base with a team who is building an initial prototype for a totally new product. Those have very different technical ramifications and “cognitive loads”.

Conversely, you can compare story points over time within one team, as it was the same team who provided the estimates. So you can reason about how long it took to deliver a 3 story point story now vs. six months ago–by the same team only.

Wait, can’t Story Point estimation be gamed?

As a system, story points gamify completing the work. Keen observers sarcastically claim they will just do a task to help the team “score a few points”.

But then again, that’s the idea behind the approach of measuring story points. To draw everyone’s attention to what matters the most: fully specifying, developing, and testing new features as an interdependent delivery team.

Moreover, all of this discussion focuses on capacity and allocation. The key measure of progress (in an agile context) is working software. Or new product features in a non-software context. Not story points completed. If you start to make goals using story points, for example for velocity, you introduce trade-offs usually around quality:

Should we make it faster or should we make it better?
Do we have enough time for Refactoring?
Why not accumulate some Technical Debt to increase our Velocity?

Story points completed are only a proxy for completed features. They come in handy in scenarios where you don’t have a clear user interface to see a features in action. For example, on an infrastructure project with a lot of back-end services, you might not be able to demo much until you have the core

Example: Adding technical scope to an already tight schedule

On a client project, I had a really good architect propose and start a major restructuring of the code base. It was kicked off by his frustration with trying to introduce a small change. A fellow developer tried to add something that should have taken an hour or two, but it took a few days. The architect decided the structure of the project was at fault.

Yet, this refactoring started to go into a few weeks. The majority of the team were blocked on anything important. He was working on an important part of the final deliverable. While the work he was doing was necessary, it would have been good to figure out any elapsed time impact on the overall deliverable, so that it could be coordinated with everyone interested.

As the sprint ended, I proposed we define the work explicitly on the backlog, and estimate it as a team. This way, the architectural work would be a bit more “on the radar”. There were around nine tasks left. The team said the remaining work was comparable across all of them, and collectively decided it was about a 5 story point size per item. So we had added roughly 45 story points of effort.

Knowing that the team was averaging around 20 story points per elapsed week, it became clear we had suddenly added 2 weeks worth of work–without explicitly acknowledging what this might do to the final delivery date. While the architect was quite productive, and claimed he could do it faster, there was still an opportunity cost. He wasn’t working on something else that was important.

In this case, story points helped come up with a realistic impact to schedule that senior stakeholders and sponsors needed to know about. The impact on the initial launch date was material. So the estimation with story points helped provide an “elapsed time” estimate of an otherwise invisible change.

While not perfect, Story Points are primarily a tool for capacity planning, not whip cracking.

So to step back, you can see that story points are a useful abstraction which gets at the core of what everyone cares about: new product features. While subjective, for the same task–as long as it’s well defined–most of the members of a team usually come up with pretty close estimates. It’s kind of surprising at first, but eventually you get used it. And you look forward to differences, because that means there may be something that needs to be discussed or agreed first. That is the primary purpose of story points. As a side effect, it can help get to grips with a much larger backlog. And plan roughly how many teams need to be involved.

However, this approach only works within relatively strict parameters and disclaimers if you want the numbers to mean anything. It is at a level of resolution that proxies progress, but makes external micromanagement difficult. If you want the team to self-manage and self-organize, this is a feature not a bug of the whole approach. Ultimately the core goal is correctly functioning new features. Best not to lose sight of that.

<< Help Yo' Friends

How to simplify a complicated process, so that even a 2.5 year old would understand it

October 2, 2019 by LaunchTomorrow Leave a Comment

A few years ago, we had a significant challenge with our 2 year old daughter. Morning and evening routines were an uphill battle every day. Getting out the door to her childminder quickly enough to make my first meeting in the morning was often a drawn out battle of wills.

It was clear she wanted to collaborate and appease us as parents. But she didn’t understand what we expected of her. Moreover, her brain development still seemed to behind. The neocortex doesn’t kick into overdrive growth until later. She was also awash hormones, which is completely normal for this age. This caused the temper tantrums typical for a two year year old. They’re called “terrible twos” for a reason. We were also frustrated as parents, and we didn’t know how to help her. Fundamentally, this was an issue of her feeling overwhelmed. And unable to sort out what’s important from what isn’t.

In a professional context, visualization works really well to help stop overwhelm. Whether to map out a business process, plan a large scale software system, or figure out a business model, it helps to have everyone involved “brain dump” onto post-its. And then to organize them. This approach unleashes a lot of latent creativity. Plus it helps front-load difficult discussions. You find out really quickly what the major challenges are with a new initiative.

How it all started

One Saturday afternoon, I was watching her learn to draw on a coffee table. I had the idea to draw out her morning and evening routines. First and foremost, I wanted to do it with her, not to her. As she was already drawing and playing around, I felt a little more comfortable drawing my chicken-scratch cartoons. Drawing was never a personal strength of mine.

So I pitched it to her as a fun project we can do together. I pulled out some bigger post-its and a Sharpie, and sat down at the coffee table with her.

First, I suggested that we brainstorm what she does in the morning. As she was coming up with specific actions, like eating breakfast, I would sketch out a symbol of that particular activity. A cartoon visualization.

As she wasn’t able to read, images brought home the message. They eliminated the cognitive load for her. She was excited to see me draw things she named on the fly. It isn’t that common of a sight to be honest. As an output of each suggestion, we drew a cartoon on a green wide post it. And pasted it on our coffee table.

Once we had a handful of these, I suggested a few others which she might have missed-for approval. I also suggested a few which were deliberately incorrect, just to make sure she was paying attention.

After this, we moved to a “converging phase” of the workshop. I suggested that she take the post its and put them in order on the wall. We had to do it together in practice, but the key was that I gave her the final say in the actual order. I was holding the relevant two post-its, and asking questions like do you “eat breakfast” before you “descend the stairs”? Doing this multiple times, we came up with a reverse chronologically ordered list of post-its that reflected her morning routine.

At that moment, she seemed to step back and view the whole process. And she was absolutely beaming, proud of both us for doing it together. But also happy that she finally understood what her parents were on about every morning. She felt less overwhelmed.

So she felt confident that she will now be able to achieve what is expected of her. Because she understood what is expected of her for the first time in her life!

Wrap up and implementation

We then did the same thing thing with her evening routine on dark blue post its. And ordered it the other way, finishing with her in bed and falling asleep.

When thinking about it, I realized the grouping was off. Some of the activities are performed on the ground floor of our house. And some on the first floor, where her bedroom and the bathroom was.

So I unwrapped a brown paper roll, ripped off two pieces about a meter long, and sat down again with my daughter. We put the ground floor post-its on one brown paper square. And the first floor post-its on the other.

“Upstairs process” mapped out, with modifications/corrections from my daughter

Finally, we hung up the ground floor post its in our dining room, and the first floor post its in her bedroom. So in the end, she had a detailed map of her daily routines, organized chronologically and physically near the place where she would actually do them.

What happened in practice

My wife and I were shocked at how effective this was. The daily tantrums nearly disappeared completely overnight. If there was push-back from her, it lasted 15 seconds not 15-45 minutes as it did in the past.

The fastest way to help her calm down, when she looked like she was about to blow up, was to walk her over to the post its. Then ask her where we were at that moment in the process. She would point to the relevant one. The emotions would calm down, as this required some cognitive load from her. And we could continue on with the rest of the routine that morning or evening.

About a year later, as I was putting her to bed, she said

“Daddy, that picture there is wrong” pointing at the one where she brushes her teeth.

“Oh really, what do you mean?” I asked.

“By the time I am brushing my teeth, I’m already wearing my PJs, not a dress”.

She was right. The next weekend, I drew out a version of the same post-it with her avatar dressed in a pajamas.

Her brain development had caught up. She understood what this map meant. She had full ownership of the process, because she’d been involved from the beginning. And most importantly, she could call out specific ideas for improvement.

Lessons learned

This experience made me reflect how powerful the principle of visualization actually is:

It can help make sense of initially overwhelming complexity. Put everything “out there” on a wall, rather than micromanage your memory.
It helps participants feel empowered and in control of what is happening. Improve motivation to implement, once decisions are made.
It helps everyone involved to view a situation more objectively. Both big picture and smaller details exist together. “what should i draw on your plate when you eat breakfast?”
In the case of my daughter, the increased clarity helped with emotional regulation. While (hopefully) not necessary in a professional environment, team “feel good” is a welcome side effect.
Cartoons and symbols don’t require the ability to read or write, in order for them to work.

Visualizing waste and complexity is a very powerful way to help get a grip on it. Clearly, the visual component speaks to us at a primordial level. Cavemen drew images. Medieval religious propaganda was based on paintings and images. This stuff is powerful.

If you want to know where to start with visualization and other tools, check out my short video course on the Hero Canvas.

<< Help Yo' Friends

Why building for the entire market bloats timeframes, and what to do instead

September 25, 2019 by LaunchTomorrow Leave a Comment

In High Output Management by Andy Grove, Intel's founding CEO, Grove suggests that Intel operated in an environment where they needed to manufacture units to a market forecast. From the beginning in the 1960s, they didn't have the luxury of selling up front and building exactly what was sold. Nowadays, this is pretty much the defacto environment for product development. Even in the case of software, where there is no manufacturing or reproduction cost, timing the scope to match demand is a core component of a software company's success.

In order to plan the release of a product, you need a clear scope of what product development needs to happen first. This includes breaking down tasks, estimating them, and then mapping the specific features to expected customer value. This way you come up with a set of features that need to be created, in order to release the product (or release it again).

How this typically plays out in practice

In practice once this is agreed, new ideas come up. New stakeholders propose specific changes or additions to that original scope. You might even want to try reaching more prospects in a related segment.

1. Add a bit more scope: The natural impulse-in this environment- is for product development teams to simply add scope to the list of stories or tasks which were already agreed.

2. Push the release back a bit: As soon as they add another feature, this effectively means more work needs to be done. So the effective date when everything will be done is pushed back. Usually this means the estimated completion date needs to be adjusted, even if this isn't explicitly acknowledged by the team.

3. Delay market feedback a bit: If the release date is moved back, the team delays getting market feedback. Depending on the size of the feature, it might be a few days in a software context. Or a few weeks.

4. Reduce probability sales: of If the feedback is delayed, you reduce the team's confidence that the product will sell. The less feedback you have, the lower the probability of hitting your sales forecast when you ultimately do release. So your probability-weighted revenue goes down, the later you release. In a sales context, "money follows speed" is common knowledge. Being able to close a deal quickly is really important, because if you don't, it's likely the customer will change their mind. And finally, if you are less certain about your sales forecast, this typically influences your overall confidence level in the product. And one of the most natural things done in this case is too…add a bit more scope.

Deja vu. The cycle repeats.

Paradoxically, the more scope you add, the lower the chances of market success of the release. Because you're innovating in a vacuum/ivory tower/echo chamber/<insert favorite metaphor here>. Even though you think you are improving your product's chances. Having too many features is overwhelming for prospects and difficult to communicate for you. The paradox of choice kicks in.

Also, if you delay the release date, you are likely to struggle to make sales until that date. There are "forward contracts" or "letters of intent", however customers will only go for something like this if they are highly motivated to get your solution. It also adds a layer of complexity and obviously a delay, thus making it harder to sell the product.

Implementation notes for startups

In the startup case, you need to get enough scope to attract early adopters in Moore's technology adoption curve. This will typically be one or a handful of related features which address a core need of theirs and which they can't address anywhere else.

The idea is that you need enough scope to go after a narrow group of people, just to get started and out the door. Trying to build enough scope for the entire market will mean you'll never actually move ahead with your business. Because you need to launch it first. The sooner you get it out there, the better for you.

Once you have nailed that first segment, you expand to adjacent segments. You modify the product to appeal to the adjacent segments. And then go sell to them. Do this incrementally, so that you have the benefit of revenues from the first customers. And confidence from initial market success.

Implementation notes for established companies

The above is true for larger companies; however, they have internal operational challenges to overcome also. In particular each of the 4 parts of the circle are often represented by different department heads. Each has his or her own agenda to push.

And while each incremental change might seem to make sense in the short term, the overall effect is the delay of a release. And no one is individually responsible for it.

source: Randy Olson | the operational usefulness of pie charts

Moreover, in a large company environment, go-to-market decisions are often made based on overall market size. While this is useful to think through e.g. positioning of a new product, thinking in terms of top-down market pie charts doesn't translate into a plan to enter the market. Different slices of the pie will want different features, with some overlap across the market.

It's ok to plan to enter the entire market eventually, but it's smarter to prove the approach works on a small corner of the market–before you expand outwards.

Acknowledge it's uncomfortable, and just do it anyway

I get it. It feels unnatural to be selling something that isn't perfect. It's easy to succumb to a fear of rejection, and just put off the prospect of releasing the product for as long as you can. I've done it in the past on my own dime. I hear the mechanism at play when mentoring founders. I see the dynamics play out in larger companies every day. Every product team with an ounce of humanity is susceptible to this.

Focus on a small subset of customers with a similar set of needs, and only build the scope that they need. Keep it laser focussed. And get it out there, even if it's not perfect. Especially in a business context, if your product addresses the core need they have, they will be happy.

Ultimately, fear of rejection just a bias that prevents you from learning what you need to know to make your new product a success. If necessary, speak to customers about their problems only–and don't show them your solution right away. Most people are happy to gripe to a friendly ear, especially if it's about something they care about. Don't make promises you don't expect to keep. But start speaking with flesh and blood customers right from the beginning.

<< Help Yo' Friends