3. Refine business+tech vision with clear success goals

Now you have a core team, and you need to use that team to check that your goal is viable: you need to leverage the expertise of that team and go from back-of-napkin calculations to some real calculations to see if the numbers add up: Does the idea stand up to deeper scrutiny? Can you get the funding? Can you get the other resources needed?

It is time to draft high level functional and technical designs, add clarity to how the idea will be introduced to prospective users (marketed), and how everything will be funded. Redo all of your back-of-the-napkin calculations with more precision and using the best data available. Shop the concept around and see what others think.

How deep should you go in this analysis? It depends. If you are building a power plant, then you need to do a full blown analysis. At the other extreme, if you are simply adding a new category of features to an existing digital product, you would probably have your core team pull the marketing data they have, do best guesses at what you don’t have, and do a one page high level design and a one page “Lean business case”. (See Defining Your Value Strategy As a Lean Experiment in the panel at the right.)

The key product features. And one of them — the one at the right — is the “magic” that will make this product special. The list of features is incomplete: it focuses on what matters most.

Next you should try to put these on a timeline. That’s the beginning of a product roadmap. See Defining a Roadmap at the right.

This is also the time to start thinking about data. Most likely your product’s users will generate data—data about how they use the product. How will you capture that data? And what will you do with it? If you postpone thinking about that until after the product is in use, then not only will you lose important early data, but it will become difficult to re-engineer the product and its supporting systems to capture the data in a way that data scientists can make sense of.

A data strategy straddles business, technical, and development strategy. Not only must you consider what use you will try to make of product data, but the product must be designed to capture data. And—crucially—the data must be well documented and defined in a way that is consistent with data across the organization: otherwise, it will be very difficult to match up data from your product with customer behavior pertaining to other products; but we will discuss that further in Step 4.

You might wonder why a high level technical design is created in this step. The reason is that for technology-based systems, you cannot separate the business approach from the technical approach. The technical approach and the business approach go hand-in-hand. The technical approach is not merely the “how”: it is also part of the “what”. This means that some of the capabilities that you define for your value strategy might be technical capabilities that are critical for the value strategy.

The “how” is also part of the “what”, at least at the highest level.

Imagine, for example, that you work for a bank and you conceive of a new type of feature that allows customers to ask for financial advice in real time, right from their account’s web page. Sounds like a good idea, maybe? That’s the “what”—it’s “what” you would like to create. So the idea is one thing, but to do a Lean business case or even check your thinking without a business case, you have to envision how that idea will actually work. The business case depends just as much on the “how” as on the “what”, and that makes the idea inseparable from the “how”, at least at the highest level.

At that point you need to select approaches for the initial attempt: Will it use live chat with real financial advisors? Will it use an AI-based system to generate the advice? The technical choices impact the parameters of the solution so drastically that you cannot postpone them. Someone will have to assess if it even can be done, and at a reasonable cost. You might even need to prototype both approaches to see which is more effective.

A business vision without a technical vision is just a dream.

A business approach and a design go together. There is a business vision and a technical vision, and together they comprise the overall vision.

To even contemplate getting to the Moon, there had to be a vision for a rocket that could get us there. A business vision without a technical vision is just a dream.

Create a Prototype?

If you have not yet created a prototype, this is the time. By “prototype” we don’t mean a saleable product: we mean a very simple version of the product that can be shown to investors or potential partners, that proves that the core idea can be implemented. It can be very crude, but it has to resolve some of the main questions about technical feasibility. It can also be used for some test marketing in which prospective users are cautioned that the prototype is not fully usable, and that you merely want to know if they would want to use a refined version.

Sometimes a prototype is not feasible. Sometimes a prototype is not necessary. It always depends. The purpose of a prototype is to give credibility to the idea, to justify the next step, which starts to entail real money.

Subtopics

Defining Your Value Strategy As a Lean Experiment

Managing Spend Rate, Not Cost

Defining a Roadmap

Coming:

Defining a Go-to-Market Strategy

Defining a Funding Strategy

Defining a Tech Strategy

Defining a Product Strategy

High-Code or Low-Code?

Is your vision to create a software product? If so, consider using low-code tools. The turnaround time is much shorter than for “high-code” approaches. That enables you to iterate more often and get to market faster. More info on how Agile 2 and low-code work together here.

 
 

Step 2 <—

—> Step 4