Launch Tomorrow

Landing Pages for your Lean Startup

Not Sure About Priorities? Clear Your Big Bottleneck

by

changed.priorities.hockadilly

There is a simple heuristic, which you can use to determine the top priority activity you can engage in-at any given moment. It comes out of the “lean manufacturing” camp. It can apply to a business as a whole, a specific product and its backlog. Your developers typically apply it, when improving software performance. Now you can use it in the context of your product development process.

Your biggest priority at any given moment is clearing your biggest bottleneck. This will give the largest non-linear jump forwards in system productivity, because of the Herbie problem . This includes business productivity (read profit). Cycle time goes down. You reduce “friction” around production.

Once you clear a bottleneck, you create another one (a relatively smaller one) elsewhere. This is the nature of this game. Then clearing that bottleneck will give you the highest possible non-linear improvement in the output of the business as a whole. In that context, if you aren’t releasing your software to production automagically with every check-in, you have bottlenecks to clear. šŸ™‚

The end game of clearing bottlenecks is simple. You become a “pull-based” organization. You can respond immediately to customer requests, if you want to, if you need to, or if it tickles your fancy. That’s a pretty valuable place to be.

[image cred: hockadilly]

<< Help Yo' Friends

Market Testing Velocity

by Leave a Comment

Andrew-G_Profiling-for-maximum-velocity-research_10.11.12

Completing tests quickly will help you run multiple tests in succession

Your success will be a function of the learning cycles you fit into
your runway.
— Tom Hulme, Ideo

The best way to discover what makes your prospects tick is to run
an experiment. If you are pressed for time, the best way to
discover what makes them buy is to run many experiments over a very
short time period.

Assuming these two would cost exactly the same amount, which would
be more valuable to you as a product manager?

  1. 1 test, which runs for one week, which gives you 99% certainty
    on your results
  2. 30 tests, which take one hour each, with 90% certainty each

Clearly the second set of tests is much more valuable. When you
finish the first test, you can form another hypothesis and test
that. One set of results directly feeds into the rest. If you want
to identify surprising results quickly, as this is most likely to
give you outsized results, option B is a much better way to enter a
market.

To some extent, it’s reversing the iterative nature of agile,
and applying it during pre-development when performing product
research. Feedback loops are enormously powerful when dealing with
prospects and customers too.

“Market Testing Velocity” can mean a lot to you in a
high-pressure situation if you want to get something going quickly.
If you complete tests quickly, you can run multiple tests in
succession.

In this case, you are doing marketing research on your
prospects or existing customers, in order to map out what they
need. Your goal is to identify what they need most, a
“bleeding neck”, as quickly as possible. You are trying
to discover a cognitive and emotional map of their needs, in order
to orient your own efforts most effectively.

If this tickled your fancy, and you’d like to read more about
market testing velocity, you’ll find out more in Launch Tomorrow.

<< Help Yo' Friends

Solving the critical 20%

by

The most challenging part of solving a problem is to define it. More accurately, to redefine it, so that it’s easy to solve. While sometimes a brute force approach is necessary, usually a problem exists because it hasn’t been thought about deeply enough. In particular, the few key variables causing 80% of the problem have not been identified yet.

The ability to solve problems systematically is a very rare skill in every profession, even highly trained ones like medicine. (What’s up, doc?)

Coming from a family of hypochondriacs, I’ve seen my share of doctors over the years. It never ceases to amaze me, that whenever I get second opinions on particular symptoms, each doctor usually gives a very different diagnosis. While the specialists all trained in roughly the same way, mostly by rote memorizing, they vary widely with respect to problem solving. Usually it takes a few visits to find a specialist which can reason through their diagnosis. Even more rare: a doctor who is willing to think about a medical problem as a problem solving generalist, regardless of whether they specialize in anything.

My grandmom had the most robust approach. She always visited 3 doctors. With 3 independent opinions, she had a high chance of getting at least one good answer. Each one usually told her something new or different, so the visit wasn’t a waste of time. It also minimized any individual bias of a specific doctor, or any assumptions which distorted the problem.

Software development is less forgiving of muddled thinking. Programming problem-solving strategies typically go through multiple iterations for serious problems. Here’s one that I use in some form:

  1. come up with as many options as possible
  2. looking for completely different assumptions about the problem
  3. use those as a springboard for related ideas
  4. come up with a test to verify a hypothesis about where the problem or bug lies
  5. once I get a test to confirm the problem, design a solution which addresses it
  6. implement the change
  7. prove that the change addresses the problem by re-running the same test

When coding, there is almost always a simple way to solve a technical problem. It requires that you understand both your problem, and how the current code is failing you.

Reducing the problem down to its simplest form, ideally where you can describe it in a sentence, helps you plan an angle of attack. Certainly when fixing bugs on pre-existing code, usually 95% of my time is spent diagnosing the problem. This is, of course, working on code without automated testing. Once I really know what the problem is, the fix is usually trivial.

If you define the problem correctly, you will have narrowed down potential causes to the critical essence of the problem, the 20% or less which is causing it. By narrowing your focus to only a few moving parts, it’s much easier to solve the problem. Sometimes this is even possible without code. Often it only requires a small change. Sometimes, you need to do a major overhaul, but if you know exactly what the problem is, you can confidently implement these changes.

In fact, finding this critical 20% is similar to prioritizing. What’s the main area I suspect? What class or method could be causing this? Once you have a guess or two about this, look for the critical 20% within the 20%, i.e. the top 4% of the problem’s causes. How can I test to confirm the exact location of the problem?

<< Help Yo' Friends

Achieve Faster Time To Market With Modularity

by

stopwatch.wwarby”
One of the key reasons scrum and agile have become increasingly popular is that Agile enables you to get to market faster. Faster time to market changes the game. If you understand why this compression of time works, you will be able to compress it even further. Agile shortens the fuzzy front end. Iterative development allows you to be highly effective, changing tactics as your environment changes. You can “parallel process” the creation of features. Most importantly, you can create modular software that helps you assemble a product with the perfect combination of features, a whole product.

Many software projects previously were just left hanging over the void, clutching the overhang, hoping for the best. Many projects initially languish in a state of cloudy vagueness. “Yeah, we should take a look at that.” A few weeks pass. “Yeah, maybe we should take a look at that.” A domain expert leaves the company. “Now we can take a stab at this.”

This indeterminate scope actually causes significant delay. In addition to the actual problem to solve, somebody needs to figure out the business case for doing the project. It’s not immediately obvious it will make money. Is it a problem worth solving?

Historically, this meant specifications, spreadsheets, and sometimes even a song and a dance to get budget sign-off. Biggish companies–particularly guilty. Once all of this was complete, and only then, the geeks wrote the first line of code.

Then it started. The pressure was on. The developers raced to finish each feature, meticulously described in arcane language and symbols. Once the developers finished their magic, a few days before the deadline, the entire weight of the project was dumped on a stressed-out QA team. A few gallons of coffee later, and after a series of boardroom fistfights about what features can be dropped since the original deadline was manic, the team releases a turd.

Of course nobody can say that. The product website sings the praises of how indisputably amazing the product is. The drooling sales team yell “To Market, To Market to Sell a Fat Pig”. The developers go on vacations to the Bahamas to drink away their bad memories of creating the turd. Then nobody buys it. Or worse, they buy it, and they tell their industry buddies the product smells, feels, and acts like a turd.

[Side Note: no pigs or other animals were harmed during the creation of this software. All of the above was purely fictional. Any resemblance to real life projects the author worked on was purely incidental, except for projects pre-dating the Y2K bug.]

ASSEMBLING A WHOLE PRODUCT

One of the groundbreaking concepts in technology marketing: the whole product. In Crossing the Chasm from the go-go nineties dotcom era, Geoffrey Moore pointed out that many technology companies grow rapidly in the years, and then hit a wall once they try to make their product more mainstream. Once the same technology is put into the hands of a mainstream buyer, such as a operations director who approves big ticket IT buys within a large company, a completely different set of criteria emerge. What changes? An 80% solution isn’t good enough. It has to be a 100% solution.

Early technology audiences are fascinated by gadgets, science, and technology. They love an intellectual challenge. For them, there is no such thing as half-finished product. In fact, they prefer to assemble components into a completely new object, one that solves a problem they have. The prototype is what they want the most. This is true even for existing technology. There is great excitement in understanding how a transistor radio or clock works, especially if you construct one from your own transistors and boards. In many cases, providing them a finished product robs them the adventure of creating something new. They don’t want a complete solution. They want to build their own.

The Raspberry Pi is a perfect example. It’s a Linux box the size of a credit card. It’s cheap. It tickles the geek’s imagination. You can use it for anything from watching Youtube videos on your large screen TV, to building custom electronics. It has a USB port. Any programmer can now work with hardware, without actually soldering anything. While it captures the imagination of creative developers, it’s just a really small, inexpensive PC. It comes in a small box. It needs a number of other parts to be useful, such as a monitor and a keyboard for example.

In constrast, mainstream audiences want a complete solution. This is called a “whole product”. A whole product fully solves a specific problem for a particular type of user. Pragmatists don’t care about potential applications. They just want to pay some money, and then be certain they can stop worrying about a particular type of problem. This is most of any technology market.

Moore writes:

The concept is very straightforward: There is a gap between the marketing promise made to the customer – the compelling value proposition – and the ability of the shipped product to fulfill that promise. For that gap to be overcome, the product must be augmented by a variety of services and ancillary products to become the whole product.

The main example he gives is that of an e-book reader, which at the time was practically unheard of. Today we have the Kindle, the iPad, the Sony Reader, all of which have been successful in the market. At the time, Moore guessed there were a number of potential applications, each for a different segment of the market. Each viewed the product through a different lens. A student wants to carrying many textbooks. A student wants light textbooks. A professional wants to have up-to-date documentation distributed electronically.

Excel is a good example of a whole product, both then and now. Not only is the software reasonably stable, there is ample documentation, thousands of forums, hundreds of books. Every office assistant will claim to know something about Excel on their CV. At the same time, you can hire a programmer which can create customized macros to query data from the internet, downloading everything from amazon reviews to World Bank economic data.

The problem is that many tech companies systematically under-deliver, leaving the customer flabbergasted. They aren’t actually seeing the problem from the non-technical perspective of specific customers. The essence of the high tech marketing problem according to Moore: “high tech deliver[s] 80 to 90% of a whole product to any number of possible target customers, but 100% to few, if any.” Some of it may be attributable to rapid changes in the technology itself. Some of it is just an unwillingness to sympathize with less technical users who don’t want the challenge of completing their whole product.

It’s similar to the old anecdote of a young boy who bought his grandmother a hockey stick for Christmas. While she’s happy she got a well-meaning present from him, the grandmother can’t really use the hockey stick for anything that she particularly cares for.

In order to turn a techie product into one accepted by pragmatists, it needs to be adapted and customized to all of their expectations. To make it even more of a challenge, each particular niche will have a slightly different set of expectations.

<< Help Yo' Friends

The Big “Land Grab” in Startup-Land

by

clock

Launch Tomorrow

Landing Pages for your Lean Startup

Not Sure About Priorities? Clear Your Big Bottleneck

by

changed.priorities.hockadilly

There is a simple heuristic, which you can use to determine the top priority activity you can engage in-at any given moment. It comes out of the “lean manufacturing” camp. It can apply to a business as a whole, a specific product and its backlog. Your developers typically apply it, when improving software performance. Now you can use it in the context of your product development process.

Your biggest priority at any given moment is clearing your biggest bottleneck. This will give the largest non-linear jump forwards in system productivity, because of the Herbie problem . This includes business productivity (read profit). Cycle time goes down. You reduce “friction” around production.

Once you clear a bottleneck, you create another one (a relatively smaller one) elsewhere. This is the nature of this game. Then clearing that bottleneck will give you the highest possible non-linear improvement in the output of the business as a whole. In that context, if you aren’t releasing your software to production automagically with every check-in, you have bottlenecks to clear. šŸ™‚

The end game of clearing bottlenecks is simple. You become a “pull-based” organization. You can respond immediately to customer requests, if you want to, if you need to, or if it tickles your fancy. That’s a pretty valuable place to be.

[image cred: hockadilly]

<< Help Yo' Friends

Market Testing Velocity

by Leave a Comment

Andrew-G_Profiling-for-maximum-velocity-research_10.11.12

Completing tests quickly will help you run multiple tests in succession

Your success will be a function of the learning cycles you fit into
your runway.
— Tom Hulme, Ideo

The best way to discover what makes your prospects tick is to run
an experiment. If you are pressed for time, the best way to
discover what makes them buy is to run many experiments over a very
short time period.

Assuming these two would cost exactly the same amount, which would
be more valuable to you as a product manager?

  1. 1 test, which runs for one week, which gives you 99% certainty
    on your results
  2. 30 tests, which take one hour each, with 90% certainty each

Clearly the second set of tests is much more valuable. When you
finish the first test, you can form another hypothesis and test
that. One set of results directly feeds into the rest. If you want
to identify surprising results quickly, as this is most likely to
give you outsized results, option B is a much better way to enter a
market.

To some extent, it’s reversing the iterative nature of agile,
and applying it during pre-development when performing product
research. Feedback loops are enormously powerful when dealing with
prospects and customers too.

“Market Testing Velocity” can mean a lot to you in a
high-pressure situation if you want to get something going quickly.
If you complete tests quickly, you can run multiple tests in
succession.

In this case, you are doing marketing research on your
prospects or existing customers, in order to map out what they
need. Your goal is to identify what they need most, a
“bleeding neck”, as quickly as possible. You are trying
to discover a cognitive and emotional map of their needs, in order
to orient your own efforts most effectively.

If this tickled your fancy, and you’d like to read more about
market testing velocity, you’ll find out more in Launch Tomorrow.

<< Help Yo' Friends

Solving the critical 20%

by

The most challenging part of solving a problem is to define it. More accurately, to redefine it, so that it’s easy to solve. While sometimes a brute force approach is necessary, usually a problem exists because it hasn’t been thought about deeply enough. In particular, the few key variables causing 80% of the problem have not been identified yet.

The ability to solve problems systematically is a very rare skill in every profession, even highly trained ones like medicine. (What’s up, doc?)

Coming from a family of hypochondriacs, I’ve seen my share of doctors over the years. It never ceases to amaze me, that whenever I get second opinions on particular symptoms, each doctor usually gives a very different diagnosis. While the specialists all trained in roughly the same way, mostly by rote memorizing, they vary widely with respect to problem solving. Usually it takes a few visits to find a specialist which can reason through their diagnosis. Even more rare: a doctor who is willing to think about a medical problem as a problem solving generalist, regardless of whether they specialize in anything.

My grandmom had the most robust approach. She always visited 3 doctors. With 3 independent opinions, she had a high chance of getting at least one good answer. Each one usually told her something new or different, so the visit wasn’t a waste of time. It also minimized any individual bias of a specific doctor, or any assumptions which distorted the problem.

Software development is less forgiving of muddled thinking. Programming problem-solving strategies typically go through multiple iterations for serious problems. Here’s one that I use in some form:

  1. come up with as many options as possible
  2. looking for completely different assumptions about the problem
  3. use those as a springboard for related ideas
  4. come up with a test to verify a hypothesis about where the problem or bug lies
  5. once I get a test to confirm the problem, design a solution which addresses it
  6. implement the change
  7. prove that the change addresses the problem by re-running the same test

When coding, there is almost always a simple way to solve a technical problem. It requires that you understand both your problem, and how the current code is failing you.

Reducing the problem down to its simplest form, ideally where you can describe it in a sentence, helps you plan an angle of attack. Certainly when fixing bugs on pre-existing code, usually 95% of my time is spent diagnosing the problem. This is, of course, working on code without automated testing. Once I really know what the problem is, the fix is usually trivial.

If you define the problem correctly, you will have narrowed down potential causes to the critical essence of the problem, the 20% or less which is causing it. By narrowing your focus to only a few moving parts, it’s much easier to solve the problem. Sometimes this is even possible without code. Often it only requires a small change. Sometimes, you need to do a major overhaul, but if you know exactly what the problem is, you can confidently implement these changes.

In fact, finding this critical 20% is similar to prioritizing. What’s the main area I suspect? What class or method could be causing this? Once you have a guess or two about this, look for the critical 20% within the 20%, i.e. the top 4% of the problem’s causes. How can I test to confirm the exact location of the problem?

<< Help Yo' Friends

Achieve Faster Time To Market With Modularity

by

stopwatch.wwarby”
One of the key reasons scrum and agile have become increasingly popular is that Agile enables you to get to market faster. Faster time to market changes the game. If you understand why this compression of time works, you will be able to compress it even further. Agile shortens the fuzzy front end. Iterative development allows you to be highly effective, changing tactics as your environment changes. You can “parallel process” the creation of features. Most importantly, you can create modular software that helps you assemble a product with the perfect combination of features, a whole product.

Many software projects previously were just left hanging over the void, clutching the overhang, hoping for the best. Many projects initially languish in a state of cloudy vagueness. “Yeah, we should take a look at that.” A few weeks pass. “Yeah, maybe we should take a look at that.” A domain expert leaves the company. “Now we can take a stab at this.”

This indeterminate scope actually causes significant delay. In addition to the actual problem to solve, somebody needs to figure out the business case for doing the project. It’s not immediately obvious it will make money. Is it a problem worth solving?

Historically, this meant specifications, spreadsheets, and sometimes even a song and a dance to get budget sign-off. Biggish companies–particularly guilty. Once all of this was complete, and only then, the geeks wrote the first line of code.

Then it started. The pressure was on. The developers raced to finish each feature, meticulously described in arcane language and symbols. Once the developers finished their magic, a few days before the deadline, the entire weight of the project was dumped on a stressed-out QA team. A few gallons of coffee later, and after a series of boardroom fistfights about what features can be dropped since the original deadline was manic, the team releases a turd.

Of course nobody can say that. The product website sings the praises of how indisputably amazing the product is. The drooling sales team yell “To Market, To Market to Sell a Fat Pig”. The developers go on vacations to the Bahamas to drink away their bad memories of creating the turd. Then nobody buys it. Or worse, they buy it, and they tell their industry buddies the product smells, feels, and acts like a turd.

[Side Note: no pigs or other animals were harmed during the creation of this software. All of the above was purely fictional. Any resemblance to real life projects the author worked on was purely incidental, except for projects pre-dating the Y2K bug.]

ASSEMBLING A WHOLE PRODUCT

One of the groundbreaking concepts in technology marketing: the whole product. In Crossing the Chasm from the go-go nineties dotcom era, Geoffrey Moore pointed out that many technology companies grow rapidly in the years, and then hit a wall once they try to make their product more mainstream. Once the same technology is put into the hands of a mainstream buyer, such as a operations director who approves big ticket IT buys within a large company, a completely different set of criteria emerge. What changes? An 80% solution isn’t good enough. It has to be a 100% solution.

Early technology audiences are fascinated by gadgets, science, and technology. They love an intellectual challenge. For them, there is no such thing as half-finished product. In fact, they prefer to assemble components into a completely new object, one that solves a problem they have. The prototype is what they want the most. This is true even for existing technology. There is great excitement in understanding how a transistor radio or clock works, especially if you construct one from your own transistors and boards. In many cases, providing them a finished product robs them the adventure of creating something new. They don’t want a complete solution. They want to build their own.

The Raspberry Pi is a perfect example. It’s a Linux box the size of a credit card. It’s cheap. It tickles the geek’s imagination. You can use it for anything from watching Youtube videos on your large screen TV, to building custom electronics. It has a USB port. Any programmer can now work with hardware, without actually soldering anything. While it captures the imagination of creative developers, it’s just a really small, inexpensive PC. It comes in a small box. It needs a number of other parts to be useful, such as a monitor and a keyboard for example.

In constrast, mainstream audiences want a complete solution. This is called a “whole product”. A whole product fully solves a specific problem for a particular type of user. Pragmatists don’t care about potential applications. They just want to pay some money, and then be certain they can stop worrying about a particular type of problem. This is most of any technology market.

Moore writes:

The concept is very straightforward: There is a gap between the marketing promise made to the customer – the compelling value proposition – and the ability of the shipped product to fulfill that promise. For that gap to be overcome, the product must be augmented by a variety of services and ancillary products to become the whole product.

The main example he gives is that of an e-book reader, which at the time was practically unheard of. Today we have the Kindle, the iPad, the Sony Reader, all of which have been successful in the market. At the time, Moore guessed there were a number of potential applications, each for a different segment of the market. Each viewed the product through a different lens. A student wants to carrying many textbooks. A student wants light textbooks. A professional wants to have up-to-date documentation distributed electronically.

Excel is a good example of a whole product, both then and now. Not only is the software reasonably stable, there is ample documentation, thousands of forums, hundreds of books. Every office assistant will claim to know something about Excel on their CV. At the same time, you can hire a programmer which can create customized macros to query data from the internet, downloading everything from amazon reviews to World Bank economic data.

The problem is that many tech companies systematically under-deliver, leaving the customer flabbergasted. They aren’t actually seeing the problem from the non-technical perspective of specific customers. The essence of the high tech marketing problem according to Moore: “high tech deliver[s] 80 to 90% of a whole product to any number of possible target customers, but 100% to few, if any.” Some of it may be attributable to rapid changes in the technology itself. Some of it is just an unwillingness to sympathize with less technical users who don’t want the challenge of completing their whole product.

It’s similar to the old anecdote of a young boy who bought his grandmother a hockey stick for Christmas. While she’s happy she got a well-meaning present from him, the grandmother can’t really use the hockey stick for anything that she particularly cares for.

In order to turn a techie product into one accepted by pragmatists, it needs to be adapted and customized to all of their expectations. To make it even more of a challenge, each particular niche will have a slightly different set of expectations.

<< Help Yo' Friends

The Big “Land Grab” in Startup-Land

by

clock

Time is running out….

“Your success will be a function of the number of learning cycles you fit into your runway”
-Tom Hulme, Ideo

Startups face a peculiar type of time management problem. They have a fixed amount of time, yet they need to learn extremely rapidly, in order to achieve the right fit as fast as they can. Not only do they have a hard funding limit, they are competing with other companies in the same segment. Typically this is just a massive ā€œland grabā€. Early adopters become aware of a particular type of problem, and they start looking for a solution. And the market is growing fast.

In order to do this effectively, effective founders systematize their learning. Dan North, of BDD fame, has come up with the idea of deliberate discovery. Dan suggests that you focus on reducing your own ignorance, at least where you are aware of it. In addition to what you learn, you can be relatively certain that there will be a number of surprises as you develop your product. Unknown unknowns could kill your product. While you donā€™t know what they are up front, itā€™s likely there are a few in each new product launch.

At first, there are a lot of business unknowns. What need do you want to address for what group of customers? Are they interested enough to pay for it? What particular group of people will want this? How can you get access to them cheaply? Groupon (GRPN) started out with mailing out offers via email. The technology they first used: PDF. Once they realized there were many people, responding to their offers, asking for more, they knew they had a winner.

Once you are clear on these basic questions, you can look at how you want to deliver and scale the solution. Software gives you a lot of automation and customization. You face numerous technical unknowns and possibilities. If you can rapidly nail down the skeleton of the architecture, that reduces the big unknowns. At the same time, if you use a lot of interfaces when coding, you have the option of replacing whole chunks of your code, once you have proven that your ideal customers want what you provide.

I will say something somewhat treasonous for a software guy: sometimes softwareā€™s just not the best choice for a product. If you can deliver a high quality individualized service, some people may be willing to pay much more for that. You will learn about their needs and pains.

By maximizing the number of learning cycles (which can be quite large when delivering a service), you actually learn a lot more about your customers and their problems. Once you’ve got that down, it’s merely an issue of how to build it.

There are a number of other options. To find out which one speaks the most to your audience, you need to use a landing page MVP. The details are in the last chapter, going into the exact nitty-gritty approach which is unlike conversion optimization or any of the other usual stuff in the context of landing pages.

And where do you find out more about that? Why I thought you’d never ask. šŸ˜€ Why Launch Tomorrow of course. When using landing pages as MVPs, you can’t just copy-paste your thinking from the usual landing page optimization website.

<< Help Yo' Friends