A use case approach to developing ecosystem metrics
Human ecosystems are complex – boundaries are fluid and socially defined, relationships are constantly changing, and definitions of roles and functions are ambiguous at best. Measuring these complex ecosystems can be a challenge.
The OECD has developed a thorough guideline for collecting, reporting, and using data on innovation focused on the business level. There is also some great work focusing on the system level by the Aspen Institute and the Regional Entrepreneurship and Development Index, which I wrote about before.
A semantic thought experiment
These models can seem overwhelming to smaller ecosystems with limited resources. Often metrics are defined without fully understanding why the metrics are selected.
I played around with the thinking framework below as I considered a response to a request for the development of ecosystem metrics. It is not fully fleshed out, but I figured I would capture it here for reference.
It can help to break the system down to the basic blocks:
- Ecosystems are made up of actors who interact with other actors.
- The ecosystem has a hierarchy with the individual at the centre who then has a position in the primary organisation of focus. The organisation is often defined by the focus of the ecosystem: startup ecosystem, business ecosystem, entrepreneur ecosystem, innovation ecosystem, etc.
- The individual and the organisation interact with other actors in the ecosystem, all of which are located in the region.
Information is associated with the individual actor – name, age, gender. This information is largely unchanging.
Information is also based on the relationship between actors. Their attitudes and beliefs, the role or nature of relationship, their participation levels, etc.. This information is dynamic, changing over time.
For example, a founder can have a duration with a company, a startup can receive capital from an investor, an ecosystem actor can have an office in a region. A founder can desire policy change from the government, or a founder can mentor in a school.
The ecosystem then becomes the sum of these interactions. The quality of the ecosystem is based on the effectiveness of these interactions in achieving a desired outcome, such as jobs or economic impact for a segment of the community.
Use cases for ecosystem metrics
When developing software, there are statements called “use cases” that are used to define requirements. These are structured like:
“As a __________ I want to __________ so that __________.”
For example, in a banking system, “As a homeowner I want to know changes to my mortgage payments so that I can manage my budget.” This statement helps focus on the customer needs instead of the system functionality.
So why does this matter? Without the use case, we may jump straight into creating an entire system just so the customer can review their home loans. But the use case did not say anything about wanting to log into a form. Perhaps the customer simply receives a text with a budget update if there is a variance?
In the same way, perhaps a use case approach would help with developing ecosystem metrics. For example, at its core:
An Actor Interacts with an Actor so that __________.
“A startup receives investment from an investor so that they can grow their business.” “A founder starts a business so that they can improve their lifestyle.” “A founder helps another founder because they desire to give back.” “A government gives funds to new businesses so that they employ local knowledge workers.”
From here, we determine what we would measure to see if those statements are accurate. We may still measure the traditional metrics – amount investment, jobs created, events attended – but we know why we are measuring. How many founders are starting a business? How many founders are helping other founders? How many startups are receiving investment? How much?
There are many models, tools, systems, and frameworks to provide guidance and examples of metrics for assessing entrepreneurial ecosystems. This could use some more thought, but as a starting point perhaps it may help to map out the underlying requirements so everyone knows why the metrics we have selected matter.