4. If the visions are feasible, build the runway

This is where the real work begins. Until now you have been mostly thinking: now you have to shift to mostly doing.

This topic has many subtopics, listed on the right. We recommend that you go through this topic end to end, and then visit each subtopic.

Always be thinking about what is needed to start getting actual end-to-end feedback as soon as possible.

You don’t have to get everything in place at once: in fact, we recommend that you don’t. Instead, always be thinking about what is needed to start getting actual end-to-end feedback as soon as possible. That will help you to prioritize where to focus.

Further Validation

In step 3 you refined the idea—your value strategy—into very tangible form: what your idea will do, how it will work, how you and others will derive value from it, how you will get the resources to start work on it, and how you will engage with potential users or customers. These are the beginnings of your product, tech, market, and finance strategies.

This is a good time to get additional opinions. However, the best way to find out if an idea is viable is to try it. SpaceX has a rule that if they are 51% certain that an idea will work, they try it to find out. They try it for real, but in a safe test setting, if at all possible.

To actually try it, you need to turn those funding commitments into actual funds. Secure the money and the resources. If you are using existing teams and your idea is merely a new set of features on an existing product, then “secure the money and resources” translates into simply getting permission to add the idea as an epic to the product backlog. If you are getting new funds and resources, then you need to create the teams needed to build enough of the idea to validate it further. Remember that you are only trying to validate the idea at this point, so keep it simple!

Prototype or Product Version 1?

There is a big difference between a prototype and a viable product. Do not confuse the two.

Be careful though: there is a danger at this point. Are you building a prototype, or an early version of the real product? There is a big difference. A prototype takes shortcuts in how well it is engineered. Its purpose is only to prove that something can be done, or will work, or will solve a need. A prototype is not something on which to base a product for real.

Building a prototype is a good idea when there are show-stopper unknowns that a prototype could resolve. Usually these are technical unknowns or market receptiveness unknowns. The purpose of a prototype is to resolve those unknowns. A prototype is not a viable product.

In contrast, a minimum viable product is not a prototype: it is polished and robust, but includes only enough features to get people to use it. A prototype cuts corners to minimize the cost and time needed to resolve the unknowns. Prototypes should only be shown to early users who are very friendly to the initiative. A minimum viable product can be more broadly shown.

If you are building a prototype, then assemble only the people needed to resolve the show-stopper unknowns. If you want some real users to get their hands on something working to see if they feel they would use it, that’s a prototype. If you want to prove that a technical idea can be made to work, that’s a prototype. Do it as fast and cheaply as you can. In that case, you are still in Step 3.

But if you are intent on starting development of the actual product, then you need to create the skeleton of your actual product development and delivery flow. That’s what this topic—the rest of this page—is about.

Architect the Culture

Before defining how things are going to work, you should consider what kind of organization you want to be. The people you choose to bring in, and the way you lead, will set the tone and establish a durable organizational culture.

An organization’s culture has a huge impact on how people operate. Culture is one of the pillars of Constructive Agility. The term “constructive” is a nod to Constructive culture, as defined by the Human Synergistics organizational culture model.

According to Human Synergistics, the members of an organization that has a Constructive culture tend to be achievement-oriented, self-actualizing, humanistic-encouraging, and affiliative. In other words, they feel enthusiastic, empowered, and supportive of each other. They are not internally competitive. They are always thinking of new ways to do things. They are not afraid of their boss. See the articles Architect the Culture and Engineer the Leadership for guidance on how to establish a constructive culture.

Structure the Initiative

We assume that your initiative is about a new product, or a major new feature set of an existing product. If that is not the case, then the rest of this section might not apply. Note that when we say “product”, we include anything that you are designing and building, even if it is for your own use.

A product is anything that you design and build, even if it is for your own use.

To build and sell a product, you need to put in place a baseline system for designing and building product features, priming the market, finding partners, getting market feedback, and supporting the product. In other words, you need to get the basic plumbing in place for the system that will implement your vision, and prepare to improve on that over time.

Don’t detail this out: instead, work with your core team to define it at a high level. Once you have that, you can consider what the initial organization structures would be sufficient for this stage. This includes deciding who will have a leadership or organizing role for each structure. See Structure the Initiative in the panel on the right.

Growing Leaders

The individuals leading each structure might come from your core team, or they might be other individuals. You need to start growing leaders, so that the core team does not become a bottleneck. See Engineer the Leadership in the panel on the right.

The traditional approach is to put someone “in charge” of functions such as “sales”, “engineering”, and “finance”, but that leads to silo thinking. An alternative is to define the roles as final decision-makers, but operate as a leadership team whereby major decisions are collaborative and never made without including all functions. In that approach, the lead of each function is expected to learn about and understand the other functions.

Also, any activity needs people who drive it. Otherwise it languishes. There also need to be people who stimulate discussion about issues. And there needs to be someone who gets things organized. Who does these things depends on the individuals. Leadership in these areas can emerge or be appointed, but it must be present.

Remember that a leader is not a “boss”: a leader is someone who has influence, possibly with decision-making authority over a category of issues. A leader is not necessarily in charge of people. And it is often the case that multiple leaders are needed over a function so that a range of issues can be synthesized, hopefully in an open an inclusive manner.

Individuals without leadership roles can also exhibit leadership in many ways, and in fact that is essential, but it is only possible if those who have leadership roles enable and encourage it.

Get the Development Runway Operational

Once you have structures and initial leadership roles defined, challenge these leaders to fill in only the details needed to get things underway. In the course of that, they should consider the guidance in Refine the Development Runway for establishing the product design, development, and delivery skeleton.

The result will be that you have the basic “plumbing” in place for your value delivery system, end-to-end. Some people call that a runway because it has all the things that you need to take off: nothing is missing, but things are only complete enough to get you in the air.

This plumbing needs to include how the product is built, and also how product data is defined and documented. If product data is archived in a data lake, but analysts and machine learning scientists cannot understand that data, or match it up with data from the same customers but other products, then your organization’s use of the data will be severely hampered.

Thus, development strategies must include strategies for how data will be defined. Just because a database does not require a schema does not mean that your teams do not need to have clear definitions of the data that they store in the product databases and the data lake.

The challenge is to integrate data management in an agile manner. If your product processes or generates data, consider embedding data specialists on teams at least part time. Train them in agile approaches. What does not work is to have someone review all data definitions before they can be used: that creates a bottleneck; but data specialists can suggest changes to data definitions in order to align them better with enterprise data models, whether those are domain models or global ones.

Engineer the Knowledge

The biggest throttle today on tech companies is access to highly skilled talent. Knowledge is strategic. You must treat it as such. The old approach of locating near tech hubs no longer applies, because your organization can hire people who live 1000 miles away from your office. You need an up to date strategy for maintaining and developing the talent that you will need. Being reactive will not work, because you can no longer afford the delay: delay translates into lost market opportunity.

A People Strategy is your approach to cultivating and growing the human talent of your initiative or organization.

a dashboard culture

knowledge domains
a culture of maintaining schemas..

Organizational Learning That Occurs In This Step

The cultural traits and leadership behaviors that are needed for an initiative.
Initial strategy for developing those behaviors and the required culture.
Initial strategy for recruiting, retaining, and developing people, according to the desired cultural norms.
How to decide what team structures to try, including how to ensure that the many teams have collective leadership and coordination.
How to decide which flow patterns to try.
How to plan for the knowledge needed.
How to establish a dashboard culture.

Quick Links

Intro

Step 3 <—

—> Step 5

4. If the visions are feasible, build the runway

Further Validation