Removing Organizational Bottlenecks

As mentioned in a previous article, continuously finding and eliminating bottlenecks is crucial for an organization. It requires openness to improve and willingness to learn. This isn’t always easy but helps you to fulfill your corporate social responsibility to reduce wasting human capital.

The presented approach works with information as well as material flow.

Keep in mind that we are talking about human beings in this context and being the bottleneck / constraint doesn’t mean that this person is not doing a good job!

To understand how to optimize your organization, it is important to understand that the primary goal of the company is almost always to make money. So the only thing that’s really important is that you sell your products profitably as fast as possible. This is called the systems throughput.

The Main Driver Throughput

Throughput is the rate at which the system is able to produce the goods pulled by the market. Sometimes the market can be the constraint too.

Because throughput is a rate, it is always expressed as output unit of time. A unit is in most cases a product. If the goals units are measured in money, throughput will be an amount of money earned per time period per unit of product.

In the case of throughput per time period, throughput is calculated as revenues received for the period minus totally variable costs divided by the chosen time period.

In the case of throughput per unit of product, throughput is calculated as the selling price of the product minus totally variable costs per unit.


Drum-buffer-rope is a concept that bases on the assumption that there is always a constant bottleneck in the value chain (recommended books). This is used to control and optimize the throughput of the overall system. If the bottleneck is not used for controlling, work in progress builds up in the process and binds resources, which in turn costs money and decreases the overall performance.

Optimize Bottlenecks

A good methodology to follow when optimizing to reduce bottlenecks / constraints is:


This tells us where to focus the improvement efforts on. Only an improvement at the constraint makes a difference.


Before starting to add capacity, we need to use the capacity we already have. “Optimize” means “doing everything possible to use the constraint to its fullest capacity.”


The job of all non-constraints is to subordinate their decisions to the constraint’s needs. They should optimize for constraint (and thus system) performance, not their own individual performance, the results of which we witnessed in.


Only once we’ve completed the previous steps it makes sense to add more constraint capacity, and thereby increase system performance. Because adding capacity is very expensive in terms of time and money, we do it as a last resort, not a first resort.


The result of the first four steps, and the reason this is a “continuous” improvement method, is that the constraint moves. This requires that you start back at the beginning, and don’t let inertia become the constraint.

Please let me know what you think, either by sharing or leaving a comment below.

Innovation Accounting

Innovation accounting is a key element of the lean startup. Using the ‘measure’ and ‘learn’ of the Build/Measure/Learn, innovation accounting enables entrepreneurs and teams to create useful metrics that offer insight into user engagement, product-market fit, and scalability.

“There’s no accounting for taste,” but for  digital product development, there is accounting for innovation.

After all, a startup business environment is all about innovation and creativity, whether you’re in a startup or corporate startup.

So we need some way to hold teams accountable. Considering that a startup is a new venture, there are no existing metrics or data or past performance statistics to use as a baseline.

Eric Ries defines innovation accounting as “a way of evaluating progress when all the metrics typically used in an established company (revenue, customers, ROI, market share) are effectively zero.”

In other words, a business developing a new product is surrounded by apparent ambiguity (how do you measure ‘opportunity’?). Here, innovation accounting creates a structure to measure progress and success.

What is ‘innovation accounting’?

The lean startup approach bases on five basic principles:

  1. Entrepreneurs are everywhere
  2. Entrepreneurship is management
  3. Validated learning
  4. Innovation accounting
  5. Build/Measure/Learn

Key to lean startup is validated learning, both the product and the client’s business. Innovation accounting is a structured way of measuring progress.

Traditional metrics, such as ROI or market share, are ill-suited to the startup. Ries emphasizes that the use of such measures only encourages exaggeration – either of the initial business plan or the predicted returns – in order to secure funding for the project.

During the product development stage, is market share a concern? Yes, it’s important to know your target user, and yes, it’s a long-term goal to capture as many of those users as possible… but while you’re still building and testing your minimum viable product, the number of users is no indicator of success or failure; the product simply isn’t at that stage yet.

So, how does innovation accounting look like?

The 3 levels of innovation accounting

Metrics and measuring performance is often tricky and three consecutive dashboards should be used for each product, each building on the last with further information and data.

Innovation Accounting 1 – Customer Focus

Key is to start with metrics that are easy to track and relate to activities that are part of the product development. Lean startup is all about understanding the needs of users, so the first level is customer focus.

Examples might be:

  • Customer discussions per week
  • Customer feedback per week
  • Conversion rates
  • Per Customer Revenue

The purpose is to keep development closely aligned with user needs and feedback.

Innovation Accounting 2 – ‘Leap of Faith Assumptions’

The assumptions you’re making about the product and the market from the beginning are a leap of faith.

The lean startup acknowledges that it’s impossible to start building anything new without assumptions. Measuring the truth of those assumptions is part of the second level of innovation accounting metrics.

There are two types of leap of faith assumptions:

  • value assumptions about the value users will derive from the product
  • growth assumptions about how new users will find your product

Testing these assumptions through prototyping, MVPs and validated learning that guide the product’s development path is at the heart of the lean startup methodology.

Suggested value metrics to test for positive user behavior are:

  • Rate of repeat purchases
  • Retention rates
  • Willingness to pay a premium price
  • Referral rates

The recommended growth metrics are looking for indications of sustainable growth:

  • Word of mouth referrals
  • Ability to reinvest revenue from one customer and into a new customer acquisition
  • Ability to recruit new customers as a side effect of normal usage

The focus is to clarify the product’s market fit and readiness for scaling in that market.

Innovation Accounting 3 – ‘Net Present Value’

Net Present Value is a reality check. It tells you what a future product is worth now. Innovation accounting NPV is based on the long-term drivers of your product’s future performance (and value); for example:

  • Number of website visitors
  • Percentage of visitors that become users
  • Percentage of users that choose to pay for the product
  • Average price paid by each user

Level three shifts the focus to the product’s financial performance.

Hold the product team accountable

Act on the data you have. Is the product team performing to plan? What progress is being made, and in what direction? Is the product development still aligned to identified user needs?

Summary of innovation accounting

Innovation accounting is one of the five basic principles of the lean startup.

It addresses the fact that a startup has no real data history or market traction, innovation accounting involves choosing key metrics that enable you to track and measure what really matters.

Pirate Metrics

We’re used to financial KPIs to monitor the progress of core innovation businesses but in case you’re a (corporate) startup that may not generate revenue until you found product market fit, this is less useful.

A startup as well as a transformational innovation team is essentially an organization built to search for a repeatable and scalable business model. What’s most important in these early stages is validated learning.

So relying on revenue as primary measure of success can be at best counterproductive. Traditional accounting methodologies can stall innovation since they are more suited to core innovation and existing business with products or services. Standard accounting practices like cash flow analysis or financial ratios can put early stage products or businesses in an unnecessarily awkward situation.

Innovation Accounting uses metrics that measure the true progress of innovation, such as customer acquisition, retention, user activity and so on.

One of my favourite models for doing this is Dave McClure’s Pirate Metrics. It defines macro metrics that can be used to model the customer lifecycle. Whilst revenue may be one of them, it’s not the only one. 

Get ready to board …. A-A-R-R-R

Pirate Metrics is a 5 metric-model (A-A-R-R-R) designed to represent all of the key behaviors of customers.

  • How many users you are acquiring
  • How many users are active
  • Whether the customer comes back and uses the product again
  • Whether your customers tell others about their experience and your product
  • How much money you are able to capture
AcquisitionHow do your users become aware of you?SEO, SEM, widgets, email, PR, campaigns, blogs…
ActivationDo drive-by visitors subscribe ,use, etc?Features, design, tone, compensation, affirmation
RetentionDo one-time users become engaged?Notifications, alerts, reminders, emails, updates, …
RevenueDo you make money from user activity?Transactions, clicks, subscriptions, DLC, analytics, …
ReferralDo users promote your product?Email, widgets, campaigns, likes, affiliates,…

Be Scientific

Without measuring progress, developing your product is really just relying on good luck. Analysing and monitoring these 5 metrics can give you a pretty good idea of potential issues. It gives you indications where you need to improve, or where the opportunities for optimisation lie.


Revenue is very important for measuring success of core innovation and existing business, but it’s distracting for transformational innovation and (corporate) startups.

Pirate metrics help to define and measure success when all numbers are (close to) zero and before you actually start capturing some of that value back.

They are leading indicators to revenue before actual revenues are realised.

They can also be used to hold entrepreneurs and intrapreneurs accountable.

Project Teams vs Product Teams

Why is it that thinking in terms of projects collide so often with those thinking of products? What is the difference between Project teams vs Product Teams?

Let’s explore this.

Until Agile, most companies had a more or less working product management which was shielding the customers from development team questions.

Historically development teams were embedded in V and waterfall models, which work very well for products where components need to be assembled. In other words you know the whole system upfront and can plan accordingly.

Software development, however, is a creative process which can better be compared to painting a picture. Even a doctor’s visit to check the reason for certain symptoms comes closer than assembling a motor. Software development deals with uncertainty.

Therefore development teams had to adapt. We stepped away from waterfall and project thinking via Agile practices such as SCRUM to DevOps. We made the ability to react to change as quickly as possible to the core of our thought processes.

At the center of this agility is a continuous learning cycle adapted from lean manufacturing namely “build, measure, learn” to ensure continuous, validated learning and to maximize product market fit for our products.

This is why I think it is good practice to clearly distinguish between product and project.

Project Teams

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.
And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.


Project teams develop specific solutions for specific customers by assembling existing products and filling the gaps with customization and configuration.

The environment of a project is not suited to develop new products. If you do, you are developing customized solutions which do not scale and have an insufficient market fit.

Project thinking is important to get certain products to the customer that need a lot of coordination and integration. Those products are typically to be integrated into a bigger landscape and require lots of customization / engineering.

The main products of a project team are the planning, engineering and commissioning services to manage complexity and risk.

Product Teams

A product team is quite the opposite to a project team. It is an in many regards well-balanced, cross functional, empowered team that stays together and continuously explores opportunities as long as the product is alive. The goals are defined per iteration and base on moving targets, such as KPIs.

Product teams are given problems to solve, not tasks or features to do.

A product lives until it is discontinued. It lives! Whereas a project is defined by its uniqueness, scope, timeline and resources.

This is a major difference, and it seems this difference is hard to understand by many. It regularly leads to misunderstandings and awkward opinions / statements about the other side, especially when one side needs something from the other side.


Project folks expects defined scope to be delivered at a certain date whereas product folks is used to explore what is actually needed and maximize product market fit. For them it’s most of the time less important whether it is this or next month. This does not mean product teams live without a sense of urgency for time to market. Actually, it is quite the opposite. It simply does not matter if you get the wrong value to the customer earlier. What counts is maximum value and high scalability which are aligned with the companies’ vision as soon as possible.

As an organization, product thinking is important to identify what the market actually demands and to decide whether the cost is reasonable to address a certain value pool. It often addresses whole customer segments.

Product teams discover new products and improve existing products.

Project teams get products to the customer that need lots of coordination and integration to solve a specific, unique customer problem. They use products.

To conclude the importance of Project Teams vs Product Teams, both are equally important and it depends on your business where you set the focus but it is important to understand and communicate the differences as well as to make sure one side can leverage the specific value the other side provides.

The empowered organization

At the core of the digital revolution we’re experiencing right now is a mindset change. More and more corporations understand their new corporate social responsibility.

Yes there are new apps, yes there are new gadgets, yes there is more data.

But no data, no new dashboard or app will help you, when your organization is set up to suppress transparency and collaboration, there will be fancy new machines but no one to take the risk to stand up and do the right things with insights from for example analytics.

It is about the need that people have to continuously learn and improve, themselves and their company.

The digital era is a fast changing environment, only fashion industry has faster cycles. 60% of what you learn today will be obsolete within a year.

For this, most companies are not prepared.

And for this reason it is required to implement mechanisms that stimulate collaboration as well as continuous learning and don’t suppress it. Only in a group we are able to learn fast enough to keep up with this pace.

If you don’t, you will be obsolete.

The proposed approach really is a series of different aspects required to collaborate efficiently.

Company goals

As discussed in my previous article, goals must consistently support overarching goals, starting from vision down to the products of a company and the actual measures in a product have to provide information of the status of the companies goals in real-time.

Incentives in corporate environments

Achieving the goals described earlier is usually enforced by financially incentivizing individuals in the hierarchy to reach the given (profit) goals.

At the same time, most individuals have a private agenda such as climbing up the ladder or earning more money to buy a bigger house.

Because of the combination of incentives and the private motivation, peers are incentivized to create silos.

This leads to the following problem:

The current incentive hierarchy prevents collaboration

Mindset of sharing

During my time in the US I learned “sharing is caring”.

If you generate assets such as services and products, make them available to everyone in the organization to use and sell to the customer.

Count the use of the service you created and paid for. Don’t do margin stacking but report the amount of reuse. It shows how central pieces in the puzzle are. It is easy to do this if you use central repositories by counting dependencies.

Digital business is often not domain specific. Carve out domain specific parts. Configure, don’t customize.

Create a culture of reuse. If something isn’t there yet, build and share it. Stop wasting human capital and stop building the same thing over and over again.

Product platform

Ask employees to publish ideas on a central platform. All employees can vote for the products listed there. That way small things that impacts many gets the deserved attention.

Use it as central place for documentation and enables others to commit to supporting the idea, either financially or with their manpower. At least in times of low business in the own area this could prevent layoffs and protect know how.

Use this tool for reporting financials and goals as well as their status. Make it visible to everyone.

Live transparency, don’t just create it.

It is important for individuals in the organization to identify themselves with the products. Only someone who does this will be motivated to learn.

Stop product related email chains. Provide a messaging area that can semantically reference the products, processes and people. This way the questions are categorized and are available for others to look up the answer.

Let the teams around this form organically and not only out of the companies structure. See the company structures more like a grouping of people with the same interest and as a channel to a customer segment instead of competing entities.

We are far enough regarding digitalization of communication that people, sharing the same passion, don’t need to be colocated. I would prefer colocated teams that commit together on the work to do (product) though.

Create customer specific projects as separate entries in this tool. Projects executed by solution teams use / group products (including services which I see as product) to fulfill customer needs that are not satisfied with an existing product that has stand alone value.

Credits as measure for collaboration

Once the product platform is in place, allow the contributors to rate the contributions. This can then be used for incentives.

Vision, Objectives, KPIs and Principles

Use tags to link all products to goals. Each team can specify own goals but needs to document and link their contribution to the overarching goals.

Provide easy access to data that can be used to calculate the KPIs that measure the goal achievement.

In this setup it is very important to formulate a clear vision, not only for how the company is supposed to look like, but more importantly what the company wants to be for the customers, the society etc.

Basing on the vision, define objectives and their key results. KPIs are to be defined as indicators that monitor the key results.

Last but not least, setup a set of principles that act as guiding rails in day to day business. They need to be as precise and short to fit all on one baseball card such as “customers go first”. Think about the audience and choose appropriate wording.

To be clear, this shall mean: no abstract and empty sentences. Everybody is supposed to act according to the principles.

This enables the empowered teams to prioritize their work and decide whether preparing internal slides or the customer is more important (to pick up the example above). It allows everybody to justify their decision based on a common set of rules. This also leads to situations that artificially urgent internal demands automatically gets suppressed.

Self Contained Offerings and Modularization

Products are supposed to deliver clear (customer) value, either in form of stand alone, or enablement value.

This value is to be part of the previously mentioned documentation and needs to be linked to customer goals.

Self contained services have to be build around shared requirements and grouped to provide a clear value. An indication that the service contains functionality that should be carved out is, that it provides different values.

A good example would be user management in software or a modular power supply for hardware.

Have the commited team run the ops for that service. If others in the organization need some more functionality, they need to commit resources. Duplicates are not permitted.

In case of the hardware example, the power supply is supposed to be produced by that specific (regional) product team.

Manage the services in the product platform. It is especially important to track the use of shared services to show how central they are to the ecosystem.

Product & Project Culture

In other articles I wrote about the difference between a product and a project. This is why I focus on the core with the following statement.

A product lives until it is discontinued. It lives. Whereas a project is defined by its uniqueness, scope, etc.

This is a major difference and it seems this difference is hard to understand by many. It regularly leads to misunderstandings and awkward opinions / statements about the other side, especially when one side needs something from the other side.

The point is, project folks expects defined scope to be delivered at a certain date whereas product folks is used to explore what is actually needed, maximize product market fit and return on invest. For them it’s most of the time less important whether it is this or next month. What counts is maximum value and high scalability.

As an organization, product thinking is important to identify what the market actually demands and to decide whether the cost is reasonable to adress a certain value pool.

Project thinking is important to get certain products to the customer that need a lot of coordination and integration. Those products are typically to be integrated into a bigger landscape and require lots of customization / engineering. In this case the main products are the planning, engineering and commissioning services to manage complexity and take the risk.

Both are equally important and it depends on your business where you set the focus but it is important to understand and communicate the differences as well as to make sure one side can leverage the specific value the other side provides.

People at Forefront

Innovation is the core of future business and the foundation for future growth and profit.

We distinguish between:

  • Product innovation: the iterative improvement of the portfolio and its products (what)
  • Process innovation: the improvements in how we create products
  • Business innovation: the improvements or changes in the business model. For example to implement a multi-sided platform and to participate in revenue streams, not primarily generated, but enabled by our offerings.

All engaged employees are stakeholders in the business journey. And it is important to give the individual a way to influence future business. This can be done via the previously described product platform.

Especially people in the first line experience the customer journey every day and have the best relationships with your customer base. This can be used to generate viable insights into what the customer is struggling with.

Let these people document the customer experience, typical workflows, tools used, personas, contact persons and pain points in a systematic way. This gets invaluable when making informed decisions on where to invest and during product ideation.

This content can then be referenced by the products in the product platform and gives a clear picture into potentials and how your current solution space matches the problem space.

Especially in larger corporations this view of your company is incredibly helpful when setting up strategies.

Management and an Empowered Organization

Up to know we discussed how to empower your employees by flattening the hierarchy, innovation needs to traverse, to be close to the market and orient the company to deliver the right products with the use of a product platform as central element.

But there is still a void that needs to be filled to keep it all together.

How do you make sure the organization is heading into this right direction and has the capabilities to implement the vision?

In other words:

  • Who makes sure we’re hiring the right people?
  • Who gives the direction?
  • Who gives purpose and vision ?
  • Who defines the rules of the game?
  • Who ensures we learn the right stuff about the market?

Some of it will be a logic consequence of an empowered organization.

Hiring for example needs to fill a future demand. If the organization however gets into the situation that capabilities are not available, there is something wrong in the employee employment strategy.

So identifying and building up the know how (especially the learnings about the maket, validated learnings) and to manage the distribution internally is one of the core activities required from the leadership team.

So planning demand ahead with the constant feedback from the teams is essential. On one hand it is important to have the right technological skills but more important is the “drive” potential candidates have.

Don’t hire to fill a gap in skills, but select self directed, autonomous people that have shown their willingness to make a change. I know that team play is a highly requested skill but it is way overrated nowadays.

People who want to perform and make a change but lack team skills will find their way to communicate. Whereas people who lack the drive can communicate but don’t make a change. It is way more complicated to change people’s motivation than to teach them how to communicate.

So focus on finding performers that can demonstrate their ingenuity.

Ask what business they would found, why, how to make money, whom they need for this. Why they didn’t do it yet. Let them draft overviews in the f2f interview and skip one or two abstract “how do you feel about…” questions without context.

Take your time but recruit continuously, not just on demand.

Hire only people with drive and passion, no one else.

If a manager is required to make day to day decisions, this will lead to resource issues later on. Taking the decisions on a product level is the job of a product team. Between products and on solution level, the teams need to negotiate.

Whether the decisions are right is measured by their contribution to the overall goal, even when this requires to step one or more levels up in the goal hierarchy.

As both teams’ goals are derived from the same hierarchy, there will be a level the new goal of the collaboration contributes to. Both teams have to add the new goal to the product platform.

If the required contribution is exceeding the capability of team (A), a minimal delivery can be negotiated and extended later. If the required delivery still exceeds the resources of a team (A), the requesting team (B) has to implement the part and contribute to the team (A) via pull request.

In some cases, team B can’t contribute to team A, for example if a software team requires certain hardware features. In this case both teams have to use the addressed customer value pool to prioritize accordingly.

So the remaining activities of direction, purpose and rules. A company vision is vital and to keep track of the distance to it is essential. For this, the leadership has to work out tensionable top level goals and support the teams in defining team goals. It shouldn’t be required to dictate the goals from outside.

The product of the company internally (the managements product) are among others the north star / vision, empowered teams and qualified resource availability. This can again be described and shared via the product platform.

Defining management activities as products makes them transparent for employees, associate them to the goals and show how this has an impact on the vision.

See it as a corporate social responsibility to maximize the efficiency of which human capital is used.

Added value and the corporate hierarchy

Typically an organization has several hierarchy levels. Each layer should add clear value to the customer. If all decisions need to be escalated, the layers get overloaded. This is where principles become important. Principles act as guiding rails for every day decision making.

They need to be precise, easy to understand and tensionable. With proper principles, bottlenecks in decision making can be reduced and the resources are offloaded.

This new capacity can then be used to focus the energy on what really matters, the customer.

Hierarchy Value Delta

Every hierarchy level is supposed to add a certain delta to the customer value creation and shouldn’t be responsible for the value, created by the layers below. The responsibility is limited to the added value delta.

Let’s be a bit more specific about what is meant by this value delta. On customers side there is, similar to the own organization, a hierarchy.

So selling a product that improves the efficiency of a plant operator at costs of $19,99 per month can typically be approved either by the operator himself or his boss.

If we are supposed to implement a digital transformation for the customer, the decisions are made on executive level. This requires a different counterpart on your own side. While the products are still sold and under the responsibility of the product teams, the “transformation pitch” is the delta added on the own executive level.

On another level you find transformation of a whole industry, the adoption of certain business models or stimulating the buying environment of a country.

What changes is the excercised influence and the scope but without the responsibility for the aggregated sales (measured with revenue). Instead, these levels are guided using their individual objectives and corresponding measures, such as market share and number of customers.

Stop Aggregating Revenue for Controlling as main KPI

If you stop aggregating revenue in the organization’s hierarchy, measure it only with a flat structure (per aggregation of the product platform) and the use of product specific measures, chances are good that this sparks lots of collaboration.

Guiding KPIs should take the products maturity into account and focus on customer value driving measures such as number of users, an app’s use per user or runway in the introduction phase, given that profit grows with increasing customer base (scalability).

This does not mean not to measure profit, but depending on the maturity, other measures give you better insights into progress and achievement of goals.

Customers in the center

To focus your efforts on maximizing ROI, it is crucial to reduce investments in functionality that is rarely or never used by the customer.

Future growth hereby can only be found by consequently investing in topics the customer is willing to pay for, either with money or data.

Please note that this implies that you shouldn’t only talk to your existing customers. Typically a large portion of growth lies with the potential customers.

So learning from the customer is the only way to build great products. And it’s not the large increments that will get you there most of the time. Large increments bear huge risks and that the customer might not see the balance between value and price.

Choose small chunks that focus on delivering either stand alone value or enablement value. Be playful about this and test alternatives for example with A/B tests.

But most importantly:

Let data decide what the customer wants.

Start including measures to verify hypotheses from day one. This is often seen as overhead and done after the product has been built, but at that point the true power of gaining insights is already over. Let insights gained by data guide your decisions how the final product will look like.

Use these insights to identify what’s valuable for the customer and forget what everyone seems to know internally about what the customer wants.

Interviews can give additional insights especially into additional use cases. They are the channel to learn from the customer. In addition they can be used to verify hypotheses.

With an open mind, they will allow you to identify opportunities and get direction for the next increment.

See the product team as your guide for a good product. Let it hike with the customer and allow them to interact with the customer. If they get to a crossroad, ask questions to verify hypotheses such as “if we go that way there might be mountain lakes to catch fish, do you like fishing?” If the customer says yes, head down that road for a while until you get to the next top and you can see whether there are lakes.

Now you already got a new business idea, next time sell a fishing rod. Put it back into the product platform.

Value of Data

Data as the new oil, but what does that mean? What is the actual value of data? And what does this have to do with corporate social responsibility?

Oil is a resource traded globally. Data is an asset, an asset that grows in value through use, similar to intellectual property. A single industrial site’s data is not very valuable. Combining the data generated by thousands of sites, such as oil pads, is a completely different story. Coupling that with data generated in different operating modes creates new insights and increases the value of data for different stakeholders.

If data is so valuable, then why do you and so many others throw it away?

Some try to determine a price for their data and try to understand what they would get when selling it. But the value in data not only lies in its volume. Uber for example connects customers with a demand. Individual consumers provide data on where they want to get to. Uber uses this to match the consumers to drivers. They also aggregate the data to provide insights into market trends and usage patterns. Uber doesn’t sell data, at least not as their primary service, but they do use it extensively to optimize their processes.

It is not about selling data, it is realizing that data is the lifeblood of an organization.

The value of data to Uber is not captured in a pricing approach. Yes, their data is valuable to third parties, but it is more valuable to themselves as they seek to optimize themselfs. Indeed, without data, they could not continue to operate.

Therefore, we can’t think of data value as simply the market price for selling it. We have to re-imagine methodologies for data valuation. The distinction, from data value to data valuation, is crucial. Data value is an asset. Your data has a certain value and is essential to understand what it is in order to make appropriate investment decisions to create products to extract this data. To understand the value of your data you need a methodology for data valuation. You need a way of working out what the actual value of your data is.

Think of data as an asset; organizations invest in assets to create value for their stakeholders. You have to assess and understand what data you have, then you have to put a value on this data so your teams recognize the value of data, treat it with respect inside your organization and increase its value like a refinery. After this, you have to invest to make sure your data is fit for purpose and ensure you have good governance in place, an appropriate data strategy, standards, systems and procedures to ensure good data quality.

Using the data is about finding out how you can use data to create value for your stakeholders. This may be by optimizing operations. It may be through more efficient delivery. It may be by using the data to generate new insights that are valuable themself such as personalized advertisements. Then you can create value by acting upon these insights. Finally, you have assess what you have learned and how to improve in the future.

You iterate between the data valuation and data value phases. The start is data valuation, something that no one has been able to properly implement and that is partly why so many data initiatives fail.

The discussion about value is not unique to data. ~1800 Karl Marx and others try to determine value. Adam Smith Bailey argues:

It is essential to value, that there should be two objects brought into comparison. It cannot be predicated of one thing considered alone, and without reference to another thing. If the value of an object is its power of purchasing, there must be something to purchase. Value denotes consequently nothing positive or intrinsic, but merely the relation in which two objects stand to each other, as exchangeable commodities.

(Bailey p. 11)

Bailey is clearly differentiating between intrinsic value in which value is something belonging to the commodity in isolation from other commodities, apart from and prior to exchange, and a relative notion of value in which value is only something that exists through the relation of one commodity to another.

Competence Center Corporate Data Quality describes two different approaches as:

ApproachCost approach: The value of a data object equals the cost incurred for reproducing an exact copy of that objectIncome approach: The value of a data object equals the total economic benefit created by that data object in the future
Key Takeaways– Considers data quality as a value determinant
– Helps manage data quality effectively
Helps raise awareness of data as an asset («price tag for data») and quantify a «minimum data value»Is easy to apply and therefore cost-efficient
– Allows internal benchmarking
Does not take the value created by data into account
– Presupposes high maturity of DQ-tools
– Provides no incentive for data managers to save data production cost
– Considers data quality as a value determinant
– Analyzes one specific process and how data is used therein
– Takes the future value created by data into account (e. g. cost savings, risk reduction, increase in revenue)
– Is very flexible and scalable
– Reveals process inefficiencies
– Is highly subjective in terms of being a company-specific and/or process-specific value indicator
– Is dependent on process knowledge and/or expert knowledge and therefore not very cost-efficient
Bottom line in terms of being applicable to data valuationDelivers valid results, but does not consider the value created by dataTakes the value created by data into account, but is highly subjective and quite costly

I propose that an organization starts with a clear vision and derives valuable data from there. As a starting point, two main categories should be created. Specific data with strong evidence of high value such as position information of moving parts (especially when the parts interact) and asset usage oriented data such as run time of motors etc. The second category contains all other data, which looks like that there is no information in it but you never know what the future will bring. In a second step assign a number that is adequate not to overemphasize data over stand-alone value. Let’s say 10% of the target business pool of a new product for the first category and 1% for the second category.

As a rule of thumb: Complex systems contain more valuable insights simply because it’s hard for humans to see patterns in it but computers might be able to unveil them.

I’m writing this partly also because I believe, that starting the process of treating data properly contains a huge opportunity for all of us. It can contribute to improving processes and therefore stop wasting human capital. This is why I see using data properly as a corporate social responsibility.


Why is it so important to understand what company goals are? Aren’t my goals more important than my customers’ goals?

The primary goal of (almost) every company is:

To make money

This sounds simple but it’s sometimes hard to keep in mind when the bullets are flying.

Especially in large enterprises, it is common to break down the goals into sub-goals such as to improve quality, increase innovation, reduce downtime, increase throughput, improve OEE, etc. which replace the main goal of the overall company (make money) during day-to-day operations.

While focusing the daily operations on optimizing them separately, companies are often not able to realize their full potential.

The sum of the local optima is not the global optima

To keep track of the performance of separate entities in the organization, each of the goals gets reported upwards every month or two (sometimes even quarterly).

This leads to a problem:

Latency is introduced into the system. And latency tends to make systems unstable.

Typically the reporting of sub-goals is done along with the goals of profit and cost.

In a perfect world, each hierarchy would break down the task to reach a goal into objectives the dedicated entity can influence.

In an imperfect world this introduces another problem:

Goals are not specific enough to be tensionable for the empowered product teams to be translated into digital measures such as “use per user of an app“.

Goals must consistently support overarching goals, starting from vision down to the products of a company and the actual measures in a product have to provide information of the status of the companies goals in real-time.

What is a Corporate Startup?

I know, you might say: Accelerator? Corporate startup? We’ve got that already.

But let’s be honest, according to HBR 94% of the managers surveyed by McKinsey said they were dissatisfied with their company’s innovation performance. So why is that, when you’re already doing it right?

Fundamentally, a startup within a company is the same as one in a garage: a group of entrepreneurs trying to make the world better using new ideas and inventions.

While to some extent the term “corporate startup” is self-explanatory, let me elaborate what is meant by it.

When talking about corporate startups, we focus on an innovation process inside companies. It is one of many types of entrepreneurship. But first, let’s focus on what’s meant by innovation:

Innovation is often also viewed as the application of better solutions that meet new requirements, unarticulated needs, or existing market needs.

In economics, management science, and other fields of practice and analysis, innovation is generally considered to be the result of a process that brings together various novel ideas in such a way that they affect society.


When it comes to corporate startups, the focus is specifically on adjacent and transformational innovation. In other words, looking at innovation targeting new customer markets and/or new solutions.

Managing Your Innovation Portfolio” introduces the “Innovation Ambition Matrix.” Corporate startups focus on the top right half of the matrix, the adjacent & transformational aspects.

The core section is typically already well covered by R&D.

Can a Corporate Startup work?

Entrepreneurship is the process of designing, launching and running a new business, which is often initially a small business, or as the “capacity and willingness to develop, organize and manage a business venture along with any of its risks to make a profit.”


In other words, an entrepreneur, by definition is an individual the takes existing resources to innovate and create something new- to generate economic value. Traits of the entrepreneur? Innovation, risk-taking, self-efficiency, opportunity recognition, ability to exploit opportunities, strong locus of control.

What is a start-up? An earlystage venture founded by an entrepreneurial individual. A startup venture is typically distinguished from an SME or lifestyle business by its degree of innovation, disruptive capacity and…you guessed it, providing (new) economic value.

What distinguishes a startup founder from an entrepreneur? The only difference comes down to that a startup founder is currently running an early-stage venture. Does that still make him and entrepreneur? Yes.

The only distinguishing factor is that an entrepreneur could have a few startup ventures, some which have grown, some which he may have exited. He may still be running his original ‘startup’- but it has grown, and can no longer be called as such. The entrepreneur actively looks for new opportunities to exploit.

Hence- the differences are temporal, and have to do with size, scale and time- of the venture NOT the individual.

So yes, corporate startups can work, why not. You need the right people with the right mindset (which is crucial) and processes.

I’d like to note though that I see it as very important to protect startup and corporation from each other.

There is a “But”

Startups can exist and thrive inside companies, but it is important to acknowledge that the tools and processes are very different.

A startup is typically financed by venture capitalists. It needs to figure out the right mechanisms to value and fund these activities, especially since a startup’s time horizon is much longer than the next annual operating budget.

In contrast, startups in corporations need to convince management of the viability of the new venture. Here it is important to note that it is not only the stand-alone value that is up to valutation, but also the associated enablement value.

This small detail is important when making a go / no-go decision for a corporation because it needs to stay focussed on the core business. Each diversification comes with an associated cost.

Corporate Startups – Transformational Innovation or Obsolescence

Average company lifespan on S&P 500 Index (each data represents a rolling 7-year average of average lifespan)

Finally, I’d like to make one final point to executives: not only CAN you do this, but your organizations MUST engage in corporate entrepreneurship to remain relevant or you will be obsolete in some years.

The chart above shows both the acceleration of companies disappearing from the S&P 500 as well as their forecast for this trend to accelerate.

While there are a number of reasons for this, the primary one is that the rate of change is accelerating and so transformational innovation is key. Put another way, the things that got your company to its current position in the marketplace will not keep it successful indefinitely.

In the first HBR article mentioned above, in which they set up the Innovation Ambition Matrix, the authors acknowledge there is no “golden ratio”. However, they go on to suggest a good starting point is a minimum of 20% investment in adjacent innovation and 10% in transformational innovation. Interestingly, in follow up research focused just on “high performers that invest in all three levels of innovation” they explain:

Of the bottom-line gains companies enjoy as a result of their innovation efforts, what proportions are generated by core, adjacent, and transformational initiatives?

We’re finding consistently that the return ratio is roughly the inverse of that ideal allocation described above: Core innovation efforts typically contribute 10% of the long-term, cumulative return on innovation investment; adjacent initiatives contribute 20%; and transformational efforts contribute 70%

In other words, to avoid disappearing like your peers on the S&P 500, you need to invest in adjacent and transformational innovation by creating corporate startups.

If you want help building your own corporate startup capabilities, the feel free to explore our webpage further.

Fail fast or die slow

I wish innovation was seen more often as an opportunity to satisfy the customer instead of a necessary management activity. To fail fast is part of a learning cycle.

The entrepreneurship required should be taught with the same priority as technology related topics. Learning needs to be embraced and made an integral part of company’s culture.

An employee shouldn’t need explicit approval to experiment and to innovate; innovation implies at least some creative spontaneity and autonomy.

One important aspect in this context is less dominant in the old world which is crucial for success in digitization:

The fail fast mentality

During my time in the US, I met people who lost their job, worked in construction and joined big companies as managers again.

If you’d have this in your CV in the old world, you can literally bury your career, instead of earnig the deserved respect to get back up again.

This creates an environment of fear where no one stands up and fights for an innovative idea.

In addition we are losing an important source for innovation, where thought patterns are transferred from another industry or life situation.

This is not supposed to sound like nothing is working. As a matter of fact there is a lot that works pretty well, especially in hardware centric business, where upfront planning rules.

Hardware business significantly differs in its cost structure from software business. It requires much more focus on the product cost during production, such as reducing plastic etc.

With software on the other side, cost is more or less fixed (except Ops) and the main lever is value. This is where concepts such as validated learning, MVP, etc. are so important while the product is already on the market to enable continuous learning.

How does your company make sure this learning is part of the culture? Do you embrace the fail fast mentality?

How to Create Meaningful Products

An innovative product, if monetized properly, can lead to a significant increase in market share and income. But how do you find one? Why is it important to concentrate on finding meaningful products?

Let’s have a look at what we are trying to create: An innovative product.

So why does the product need to be innovative?

Not without a reason this question should be answered first. It is often a lot harder to be the first in the market when introducing innovative, meaningful products.

Being second and adapting a certain product, for example to another market can often be more attractive than creating a new product.

Another motive might be the personal ego or the drive to leave footprints. While it feels very rewarding to create something from scratch, you should ask yourself whether it is worth it and whether this “drive” will fuel you till the end.

There are various reasons why you would want to create something innovative. And I’m the first to advocate for a “do it”, but please, be clear about WHY you do it.

The misconception about innovative minds

A widely spread misconception is that innovative minds such as Leonardo Da Vinci, Newton, Einstein, Schroedinger, Hawkins, Maxwell, Galileo, Bell, Curie, Faraday, Kepler or Charles Darwin were simply geniuses.

If you look closer though, you will find that all disruptive innovators had certain things in common:

Some of the most innovative, meaningful products and ideas are very complex behind the scenes but easy to understand with a decent model. This makes it tempting to attribute all the hard work to create the model to the pure genius of the author.

Innovation is to cause change in a controlled way.

Why do customers value products?

Customer value is satisfaction, experienced by taking a given action relative to the cost of that action. Typically this action is taken to achieve specific goals.

In other words: Product value is a perceived benefit that helps your customers to achieve their goals.

Knowing your customers’ goals and to address them with your product with an appropriate ratio between benefit to cost increases your chance for a win-win.

Think about your customers’ goals, not yours!

The primary goal of (almost) every company is:

To make money

Especially in large enterprises, it is common to break down the goals into sub-goals such as to improve quality, increase innovation, reduce downtime, increase throughput, improve OEE, etc. which replace the main goal of the overall company (make money) during day-to-day operations.

While focusing the daily operations on optimizing them separately, companies are often not able to realize their full potential.

The sum of local optima is not the global optima

The knowledge about the goals, corporate culture, innovation strategies and internal politics of a customer helps to determine the appropriate price.

Every pitch, flyer, link, poster, and whitepaper must address these goals.

The definition of meaningful is something that has a purpose, that is important or that has value.


So if a product is supposed to be meaningful, it needs to provide value, and help customers reach their goals.

Why do customers love a product?

There is more to it than “just” value that makes someone love a product. According to GoodTherapy love is:

  1. Extreme feelings of attachment, affection, and need.
  2. Dramatic, sudden feelings of attraction and respect.
  3. A fleeting emotion of care, affection, and like.
  4. Some combination of the above emotions.

All the mentioned definitions, even though made for loving another human, can be adapted 1:1 to ingenious and meaningful products

  1. Some people check their social media every few minutes until it shows addictive behavior
  2. Some users religiously swear on using only certain computers with fruits as logo, others religiously reject them
  3. The amount of care given to the virtual characters for example in online games sometimes leads to less social bonds in the real world

As you see, many attributes apply to (innovative) products in a similar way.

Having that said, as you are the one designing the product, it’s up to you what character your new product shall have.

So please keep in mind while designing your products:

Show respect and act ethically. Do not intentionally addict customers for the sake of profits

Technology is supposed to augment and simplify navigating life; to make it more joyful and enrich the experience. It is not the other way around, that we serve technology.

The enterprise environment

In many cases, companies had a more or less working product management which was shielding the customers from development team questions such as “what do you want to achieve”. This often prevented disruptive innovation.

The development teams were embedded in V and waterfall models, which work very well for products where components need to be put together and projects.

Software development, however, is a creative process that can better be compared to painting a picture. Even a doctor’s visit to check the reason for certain symptoms comes closer than assembling a motor.

At the same time the handover date, scope of work and resources/price need to be communicated upfront. A timeline is required to, for example, ramp up the complex marketing machine for the new product.

This is also btw, why I think it is not good to speak about projects in product development:

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.
And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.


A product team is quite the opposite. It is an in many regards well-balanced, empowered team that stays together and continuously explores innovative opportunities as long as the product is alive. The goals are defined per iteration and base on moving targets, such as KPIs.

It’s literally a clash of two systems, military command & control vs. empowered, highly trained special forces dropped behind the lines. While in military the reporting structure seems to be well integrated, in organizations they are often not.

Understanding the difference is very important if you are to build your innovative product in an enterprise environment.

The process of finding Product Market Fit

The process of finding an innovative product that fits the market looks pretty straight forward but is maybe the toughest job in a company. It often requires a lot of ingenuity.

A Minimum Viable Product is defined in many different ways and you will get 30 different answers if you ask 15 Product Managers.

For me, it is defined as a minimum increment that has the characteristics to be valuable, usable and feasible.

Please note the difference to Eric Ries’s hypothesis testing or the smallest possible experiment.

Such a hypothesis test could be a paper-fold prototype to show an aspect of the new product to customers, but it is not sellable. A hypothesis test serves exactly one purpose, to validate a hypothesis quickly to rapidly reach product-market fit.

I see the complete product development process as a path in a tree, starting from a root element, developing towards leaves. Without ever reaching an end, until the product gets discontinued (compared to a project, which has an end).

I believe both concepts work well together to find incredible solutions. In the mentioned tree, every edge, leading to a new node represents an MVP. The hypothesis testing hereby defines whether to go left or right for the next iteration / innovative leap and sets the direction with minimum investment.

In other words, there are two tracks going on in a product team at every given time:

  • Product Discovery (WHAT): Finding a Product Market Fit through validated learning using hypothesis testing. In the product discovery, the team is to find a market need that is scalable and valuable
  • Product Delivery (HOW): Smallest increment to deliver value to improve the Product Market Fit

In many organizations, Product Discovery is separate from the product team which pretty much cripples the team and degrades the whole “product team” to a feature delivery team or extended workbench. You can’t expect innovative solutions from such a team.

A truly empowered product team determines the product’s destination (within bounds) on its own with high-level targets, set for example with OKR.

The required skills are to understand the market, the domain, being able to define a business strategy, to develop a product strategy, deliver on it, make money, do consulting and often also sales as well as business development at the same time.

You could open a startup with such a team. I didn’t initially call it without a reason maybe the toughest job 🙂

The art of having ideas

There are maybe as many creativity techniques out there as people trying to have an idea.

Brainstorming, freewriting, swot, five Ws, etc. all have fancy names but do typically more or less the same, they force you to act and think outside the box, either in a group or as individuals.

Every time you take action, you allow your mind to let go of a thought it otherwise would try to groom. Taking action on an idea enables you to have more ideas afterwards.

I call this the hydra method according to Greek mythology where Heracles (Roman = Hercules) was sent out by Eurystheus to kill the Hydra. Every time Heracles cut off one of the serpent’s heads with his mace, the Hydra would regrow two new.

An activity can mean writing it down, sketching the innovative idea or creating a prototype, etc. So some form of doing or taking action. It can also mean to delegate the task of exploring an opportunity, work with a university (Capstone, Ph.D., etc) or discussing it with a team of open-minded colleagues.

You can use Hydra to increase the flow of ideas in all situations from innovative business ideas to vacation ideas. Because you just need a blank notebook to get started, you can do it everywhere, no matter whether you have a power supply or not.

The core of Hydra can also be found/combined in other techniques, such as brainstorming and slow-motion multitasking.

Must have documents

From my experience, not a lot of documents are really important in a product team, but the few remaining are so important that I would not advise developing anything without them.

The documents are centered around the following questions:

  • Why do I build the product?
  • For whom do I build the product?
  • What is the value I’m creating?
  • How it the value delivered to the customer?
  • What is the impact of my product?
  • What’s my competition?
  • How do I measure success?

All documents are considered living documents and should be managed with a version control system.

You will get access to vector graphic templates of the canvases I use, via the newsletter soon.

All documents should be visible in the area where the team works at any time, for example in the team room, etc. The team is supposed to be able to have informed discussions during meetings.

Most of them can be found in the Design Thinking process and SCRUM.

I hope it also gives everybody who thinks Agile means “we don’t have to plan” an idea of Agile planning.

Porter 5 Forces

To gain an understanding of the competitive landscape and the attractiveness of the market for the innovative product, M. Porters 5 Forces is a great methodology to apply.

The understanding of how the threat of new entry, buyer power, the threat of substitution and supplier power apply pressure on the market which increases competitive rivalry helps to understand patterns and often explains the behavior of market participants.

If you will, the 5 Forces show you how the sandbox looks like in which you want to play with your new product. This is why I would advise doing Porter first whenever you think about entering a new market.

Lean Canvas

20 years ago it was common to create extensive 300+ page business plans before doing anything else. Most of the time with the same result, once created, it never got updated or even used in day to day business.

The core of the one-page lean canvas is the same as the 300-page document:

How to deliver value to the customer?

You can use the Lean Canvas to architect and communicate your ideas to team colleagues or investors.

For a very good description of the different areas please see Ash Maurya’s description on leanstack.

Please note, that a Business Model is not a Revenue Model. It is helpful to distinguish wherever possible. Often though, many use the term interchangeably.

A Business Model describes what and how value is created as well as how it is delivered to a customer. It is about value. A Revenue Model is about monetization.

Typically the Revenue Model is anchored in the lean canvas in the Channel and Revenue Streams section.

The reason it is good to distinguish this is that in enterprise environments, value is typically created by the product team and the monetarization by the sales machine. The salesforce hereby addresses many different vertical markets and regions.

By making this cut, misunderstandings in responsibility can be avoided and a clear scope for discussions is set.

In a truly empowered product team, the sales role would be represented in the team as well but as the product and its target market grow, the benefit of separating this role gets clearer. So whether it makes sense to integrate this role into the team depends on your business and its maturity.

Revenue Model

A revenue model describes, how you intend to make money with your product. It sketches who pays for what and how.

I’m not aware of a standard template for the Revenue Model and typically use Visio to draw a component diagram depicting the value- and revenue flow in one view. In many cases, I visualize this as an overlay of the Lean Canvas itself to show how different customer segments interact.

User Journey

A User Journey visually shows the interaction of a user with a product, process, or in general a system.

It can be used to capture customer interaction with an existing system during the Product Discovery.

The User Journey describes step by step what the user experiences while executing certain tasks in a sequence to get a job done.

The level of detail can vary from 10000ft view down to a fine granularity. In addition to the tasks, the team notes the emotions the customer is experiencing and connects the moods with a line along the sequence of actions.

After finishing the User Journey, it is easy to detect which situations need improvement. Typically delivering solutions to improve the most negative feelings in the first iterations should provide enough value to the customer to convince to purchase. (If priced appropriately)


Personas go hand in hand with User Journeys. Personas give the anonymous, typical user a face in the team. They create empathy in the team.

During Product Discovery the team identifies different archetypical users. They represent goals, Jobs To Be Done (typically referred to as JTBD) of a large group of users.

A persona is presented on a poster-sized one-page document. Typical attributes captured are: Tech seavyness, age, occupation, location, motivation, goals, frustrations, personality, picture, etc. The captured attributes vary a lot from domain to domain.

Unspecific personas such as “user”, “customer” etc are not allowed.

Product Vision

A Vision describes the desired state or dream in the future. Watch out that it doesn’t just sound like a dream though. The Vision can be on a company level, or in large enterprises broken down to a finer granularity.

For a product team, it is helpful to use a product vision. It needs to be in sync with the corporate vision though.

A product vision must follow the overall theme of the product (line). Be very precise with your wording. For example instead of: “Create transparency and insights for cities” use “Create transparency and meaningful insights for city infrastructure“.

The differences are often small, but have a huge impact and help to drive conversions. In the example above, adding “meaningful” causes to think about what meaning for a customer means and how it can be ensured to provide that meaning, what a customer wants to achieve, etc.

Epic Map

Epic Maps structure User Stories visually in one view and allow to easily communicate progress to stakeholders and in the team.

In an Epic Map, Epics are grouped into categories and broken down into User Stories. I haven’t seen this representation in tools such as Jira, which makes it a bit tedious to maintain. But it’s a great way to improve communication.

So User Stories are created in the Epics Map, moved around, refined, split, etc. and once their position in the big picture makes most sense the stories are added to the Backlog. Starting from there, both systems need to be synchronized from time to time.

When working with colors and stickers, it is very easy to communicate overall progress towards releases and dependencies.

You can see it as a visual representation of the Product Backlog with additional structure. It looks similar to a Work Break Down Structure.


As always, risks have to be considered and proper mitigation needs to be identified and tracked.

In addition to technical risk, risks in the market (demand, financial markets, customs delays, etc), company culture the business model, revenue model, etc. has to be captured.

Because of the iterative nature of SCRUM though, the list of risks is typically not as excessive compared to traditional project management, as the team is flexible to reprioritize the Product Backlog. So risk naturally comes more often from uncertainty in the environment than feasibility.

Product Backlog

The Product Backlog is a prioritized list of User Stories written from a user (persona) perspective (requirements) by the product owner.

A typical User Story has the following structure “As a PERSONA (Who), I want to ACTION (What) so that I can BENEFIT (Why)”.

It is important to note that a User Story clearly states what’s in for the customer. In other words, it refers to values and goals.

Unspecific personas such as “user”, “customer” etc. are not allowed. The same goes for stories not having a user in focus and referring to an internal persona, for example “Product Owner”, “Stakeholder” etc.

A persona is someone interacting with the system and someone benefiting from the provided value.

User stories are estimated by the team. They describe value (What). The team pulls as many stories into the Sprint Backlog as the Velocity permits.

In the Planning Meeting, the dev team breaks User Stories down into Tasks (How). During this, the PO is only required to answer questions and doesn’t participate in the estimation.

Once a Sprint is completed, the team hands back items that meet the acceptance criteria from their perspective and the (more general) definition of done in the Sprint Review.

The PO either accepts a User Story and sets it done or adds it back to the backlog.

The sum of “done” User Stories per Sprint is called increment. An increment must be shippable to the customer. But the PO eventually decides wheter he wants to do so, or not.

The Product Owner is responsible for the Product Backlog. No one is supposed to add items, modify or reprioritize without the mandate from the Product Owner. Stakeholders can provide their input, for example their priority, but the final call is made by the PO.

One word about priority: The reason to prioritize is to reduce complexity and allow sequential processing. This means, there can’t be multiple priority 1s.

Goal Sequence

Roadmaps have one major flaw in development: They don’t work (when they are too detailed)

As said earlier, development is a creative process. Putting into a roadmap “what”, “when”, sometimes even “how” combined with the fixed team size (resources) sets the team up for failure.

Interestingly medical doctors seem to have fixed this perception with their customers long ago. Try to set up a roadmap with a doctor include payment, delivery, KPIs, and so on.

The answer you’ll get is most likely “I can’t agree to this” because: “you are a significant part of the solution” and / or “everybody is different” etc.

At the same time, roadmaps are important because they allow other entities in large enterprises, such as marketing, to plan.

So as often, the best way lies in between. The theme can be communicated and the customer value, but avoid by all means to have a roadmap of features.

To provide guidance to the team, better set a sequence of desired business outcomes instead of roadmaps.

Here is what Marty Cagan proposes: Use Business Objectives, describing the specific, prioritized objectives for each product team.

The best way to define Business Objectives I’ve seen so far is OKR. You can find a very good book about OKR here.

So create a list of OKRs and tell the team WHAT, as well as KPIs to measure success and let them figure it out.

You’ll be surprised by what a truly empowered product team can accomplish. This is where the team will need the Vision as a context.

If used properly, the same OKRs can be conveniently used in corporate performance planning.

Idea potential evaluation

Once a list of ideas has been created, a phase that requires a lot of discipline starts: To prioritize what ideas should be developed, in other words, the idea potential evaluation.

This evaluation is typically difficult because in it’s infant state it is hard to estimate the impact of an idea. The following describes a mechanism that works very well for me.

The core of a profitable business is scalability and value

Increasing complexity and effort means higher resource usage or slower time to market with constant resources.

More gain or removed pain, on the other hand, increases the value of the solution.

If you put this in a formula, you’ll get:

\text{Ranking} = \frac {\text{Pain or Gain * Number Users}}{\text{Complexety of Solution}}

As the concept focuses on customer value, combining it with Value-Based Pricing enables you to answer the question about an approximated market price, as well as the revenue potential, very early.

The idea with the highest-ranking shows the best value to effort ratio.

Do patent research

In 2018 308,853 patents have been granted in the U.S. 159,724 directly related to digitalization in data processing, Transmission, wireless, image processing, data processing, etc.

These numbers alone show, that getting a product to the market is almost impossible without violating patents if no research is done. Patent research is a central part of the product business.

To do research, use the U.S. Patent and Trademark Office (USPTO) to research prior art and note down how your idea is different. It is wise to use an IP attorney to make sure you are legally ok to sell your product and protect your own IP.

Patent research can be a great way to check how others solved a particular problem as well.

Check for standards & regulations

A topic that is often overlooked is to comply to certain standards such as FAA and FCC. Which authority is responsible depends on the country you live in, but wireless compliance is a topic in almost every country.

FCC compliance ensures your product is not interfering with other radio communication. Please note that a product doesn’t need to purposely emit radio waves (see EMI). You still have to comply.

Please note that your product must comply with every country you want to sell your innovative product in.

To export a new product, it needs to get export control (ECC) clearance. Clear means that your product is OK to be exported.

Create a prototype

Prototypes are the heart of a hypothesis-driven development. They can be used to generate proof points for a variety of different areas.

Never underestimate the power of being able to prove a point quickly!

A paper fold prototype or mockup could, for example, be used as an MVP test to be shown to a customer, collect feedback and show fast turnaround time.

A demo webpage can be used to evaluate the market resonance and willingness of customers to purchase a product or service before it is even fully built.

In yet another situation, a prototype (3D print, Algorithm, etc), is used to eliminate a technical risk and show the feasibility of a concept.

When done properly, prototypes often give the impression of a lot of progress to others. This can be dangerous at the same time if stakeholders do not understand what the purpose is and expect the same speed from the team going forward.

So be aware to maintain a certain quality standard or get the (written) commitment from everybody upfront that this deliverable will not be integrated into production.

Important KPIs

Depending on the type of innovative product you’re building, some indicators may change.

KPIs need to measure success on an appropriate granularity to provide the necessary foundation to make decisions without adding additional work.

Plan to build the product in a way, that the application automatically generates the required numbers for you in real-time.

When you define your goals with OKR, as discussed earlier, a KPI is simply measuring the key result.

Always have the primary goal of your company (“To make money”) as one of your KPIs in some form. This could be achieved by breaking it down to measuring the number of paying users while not increasing the cost.

Please note that there are times where you purposely sacrifice revenue to, for example, generate a customer base and get data for business models basing on analytics. In these cases, it is important that you have a scalable model and your cost stays more or less constant.

Also, always be sure to collect data that contains a higher density of information, even though you might not know what to do with it yet. Think about GPS positions of people for example. One can immediately think about correlation, accumulation of reported positions, distance to fixed positions, etc. to monetize in the future.

My point is, there is raw data that contains by nature a lot more possibilities than others.

Have in mind that there are also counterproductive KPIs, for example to measure productivity in lines of code. This is absolute nonsense.

Think about chess: A good chess player uses fewer moves to win. If he was measured in how many moves he uses to win, a game would take forever.

Being successful is about using fewer moves than your opponent to achieve the same result

So as a general rule of thumb, set up KPIs around resource usage, proof of value and profit generators. For example, the number of connected assets, the number of users, number of uses per day, usage time, follow up actions, server time used, number of inquiries, number of requested trials, customer acquisition cost, revenue, maintenance cost vs development cost, customer rating, etc.