Startup Ecosystem Portals Post-Mortem

All the reasons why your startup ecosystem portal stucks and what you need to know to make the transition to a non-portal approach

Let's be clear and honest from the beginning. This is a read for a weekend but definitely you won't want to wait for the weekend if you are about or in the middle of planning your startup ecosystem portal. We really hope that this startup ecosystem portal post-mortem post can be used as, similar to most of the free content and knowledge that we have on the Startup Commons website, a global "must-read" thing for those that are in the planning phase to develop a startup ecosystem portal.

For many years, the Startup Commons team has been invited to take part in different RFP processes and projects to develop and implement startup ecosystem portals with the aim to help navigate ecosystem actors (startups, supporting providers, investors, corporates, mentors, etc) more effectively within the ecosystem, improving the connectivity among them and therefore removing barriers to help anyone get access to the different available resources within the ecosystem.

And while we thanked all the invitations, we participated in few of them but also we decided to not participate in the majority of them due to misalignment with our own mission. We, as a company developing interoperability solutions for startup ecosystems, couldn't contribute to creating another silo. It is a matter of principles. When we properly evaluated each of those cases (we want to keep them anonymous for confidentiality reasons), we noticed that those RFPs and project requirements to build startup ecosystem portals had been poorly designed, targeting to develop portal solutions that were not reflecting the logic behind what startups and other actors need, and therefore contributing to a low impact for entrepreneurs and startups. Additionally, the RFPs and projects alikes were fully misaligned with the direction the digital world is headed, with the technology, turning their back to the future evolution of the technology, developing short-term vision solutions with old techstack and technology architectures that will end up in inefficiencies or wasted resources. And what is most important, they became useless because information was outdated soon.

Once those startup ecosystem portals were delivered, we proceeded to evaluate their real impact, finding the following problems:

And while these portals became a good marketing tool to provide a good overview of many things, they simply failed in their efforts to serve the main purpose: help ecosystem users navigate within the ecosystem, giving them what they need at the right time. 

This bad user experience encouraged the Startup Commons team to dive deeper in this topic so you can learn more about the next generation of online startup ecosystem portals. We simply call it the Non-Portal approach.

Building the startup ecosystem portal use case

First of all, one fundamental thing to understand is that geographical startup ecosystems are very fragile to political changes, where prioritization and maintenance of the supporting infrastructures for innovation and entrepreneurship are often very likely to be politicized. When a new government enters into power, it is very likely that existing strategies, budgets, key people, processes, tools, data and history are at risk to be changed, where significant learning, knowledge and progress will be lost and many things again start from the scratch and therefore ecosystems simply get stuck in their development. Therefore, as a first step, and before any digital development, there should be specific dedicated neutral entity with mandate from all ecosystem key actors, proper resourcing and long term approach, looking at the needs of all sides and representing all the key segments of the ecosystem, to become a neutral custodian of common ecosystem infrastructure and a hub for common information and data sharing, with sole focus for looking at the benefit of the entire ecosystem as a whole. We call it an ecosystem operator.

This ecosystem operator function is missing in the majority of the ecosystems, regardless of their maturity level. There are no sustainable resources defined for such setup, available for ongoing and long term data management and digital development efforts. And a typical reason for this is the lack of digital transition vision along with missing commitment to pursue it. Another related reason that is common in digital transition projects, is the typical separated relationship of “business” and “digital” teams, departments, or organizations. Where a more merged approach is needed for a team, where knowledge and expertise of both sides are embedded in one.

Regarding the startup ecosystem portals, they are also well known under different terminology like startup ecosystem one-stop shop or startup hub. In any case, when you hear an ecosystem deploys a portal, if you’re like an entrepreneur it means you can do everything you need to do for your startup in a single location, getting access to digital services and information offered by different ecosystem actors to help you navigate within the ecosystem easier, faster and finding support for the challenges related to the different stages of the startup journey, from formation to growth.

Entrepreneurs and startups are clearly in need of answers that are relevant to them and their unique circumstances. They are making decisions every single day. They come and go to different places and digital platforms to learn, connect, develop, sell, etc. They interact anytime, anywhere. If we think for a moment the amount of information that is demanded for entrepreneurs developing companies with all kinds of different business models, industries, strategies, people, etc, then it becomes clear that data is definitely a key asset that must be unlocked and properly managed. Therefore, with such reality, what should it be built to really help entrepreneurs, startups and other ecosystem actors?

Let’s reflect back for a while to review and understand some past portal approaches in order to understand what to build for the present and future:

The most basic portal - Yahoo!

The first and most recognizable portal I remember is the original Yahoo!, which had a directory view, in which the same information was provided to everyone and “forcing” users to navigate to find the information they need.

The Search Engine Approach

Google is the maximum exponent for this approach, providing users direct answers based on the questions (search queries) they make, with additional effort of trying to match the results based on the profile they can have on the user (language, location, search history, etc.) Users come to get answers when they have first identified that they have a question and know how to formulate that question, i.e. know the right keywords to ask

The Social Network Approach

And more recently, we have the social network approach, with Facebook as the clear example, with its ability to distribute/target messages with great (questionable) accuracy to users where they already are based on their profile and patterns, regardless if they have already identified or formulated the question. 

With the previous references in mind, as a simple thought exercise, imagine an entrepreneur with a question that she/he can't even clearly formulate. Now imagine that via analogy of a medical condition and trying to find a useful answer via a portal with filtering type of intelligence without proper search. Now imagine being able to search via Google compared to that. It’s definitely better, but still far from what you would like to do, compared to if you could consult a real doctor with related subject matter expertise. And likely, you would definitely not want such sensitive information to be shared in Facebook to have such a public forum to collect your data and provide answers by drug companies or only commercial services that can afford to target you (pay for ads for you to pay for service you will get). But nevertheless the way you would like to get suggestions for actions to take would be optimal to get suggestions based on your profile without needing to know what to ask and whom. But naturally in such a way that you are not actually sharing your profile outside of your control and without being able to control what messages from who can even reach you (mute those that are not useful).

This is the kind of experience we are visualizing. Entrepreneurs and startups should get responses for their ventures based on their local context, history, profile, achieved milestones, etc. and even getting responses and services without the startup having to ask or request a specific service, simply because there is intelligence that tracks them based on the ecosystem interactions and startups progress.

Considerations

When considering solutions to cope with these challenges, we often see that key principles are missing or were not taken into account during the process to design the RFP/project. These principles are key in order to make sure that the collaborative and open nature of ecosystems is encapsulated by any solution that is implemented and deployed for the ecosystem, making sure that everyone is benefiting:

• Only things that can be understood, can be developed - First of all, RFPs are designed by people whether they have an ecosystem or digital understanding but definitely the majority of them don’t fully understand the big picture from business and technology perspectives. It is very rare to have the unique view and expertise of operating in the intersection of innovation, entrepreneurship and digital. In a way, RFPs are similar to "surveys", where the quality of answers are dependent on the quality of the questions. So how the RFPs have been designed have a defining impact on the best potential outcomes.
• Understanding the needs - Startups want ecosystems (ecosystem builders/developers/operators) to proactively provide services and accurate information that are relevant to them and their current circumstances. Proactively service delivery means that the ecosystem delivers a service to a startup when a startup journey event occurs, without the startup having to request the service
• No-vendor lock - When looking at developing and deploying ecosystem solutions, it is key to make sure that the solution to be developed is being built under open standard principles, to guarantee independence and vendor neutral and to enable flexibility, choice, interoperability and efficiency and in general to avoid situations where future improvements to solutions are imposed by global roadmaps that have nothing to do with the needs and context of local ecosystem actors
• Sharing is caring - RFPs should define how the solution can connect with local systems and what standards should be adopted to make these connections, enabling collaboration with organisations that support those standards and also “forcing” you to participate in local technical strategy groups and roundtables to ensure that consensus is built to benefit the majority of the whole ecosystem
• Data at the core - RFPs are usually too much focused on features and functionalities related to information directories, aggregation and visualization and too little on the assets that really matter: data. The biggest focus should be on capitalizing data and making it findable, accessible, interoperable and re-usable, with special focus on data quality so that machine learning and artificial intelligence can play a key role to enable more automation, accuracy, etc. Data collection and making data available is the easy part and only 25% of the job. Distributing it effectively to the right audience, at the right time, via the right channel is the real challenge.

• Addressing data at the source - The single source of truth is distributed. It is in every system where the data is originally generated, based on the interaction between the users and services.
• Avoid extra work to users - We, the users, hate duplicating, modifying and maintaining information so there’s no point to design an experience that “forces” them to go to another place to create another user account to duplicate information that already exists somewhere else. 
• Openness - Instead of considering data is close/private, and then considering what should be open, consider that data should be open by default, unless there is specific reason for it to be closed
• Someone has to operate - Go small on technical planning and big on how to establish function to operate it. Ie not portal or technology first and then thinking what resources are needed for it, but rather design the operator and define how it should operate: develop, operate, coordinate and maintain ecosystem infrastructure, coordinating standards for collaboration and eventually guarantee continuity, as any other infrastructure operates in the world. 
• Sustainability - Project sustainability is directly related to big volume, velocity and variety of data in order to provide value for data owners and other stakeholders and therefore monetisation model. Ecosystems are much more complex structures to orchestrate than even any big organizations are, where proper sustainability is extremely unlikely to happen in the timeframe of a project like an ecosystem one-stop shop project. Achieving sustainability requires very systematic and balanced development over any time period, where the level of ambitions and expectations of features and functions needed to be operated, are in fact kept in balance with the realistic sustainable people and financial resources available or resources within reach, during the available operative runway. 

Looking Ahead: Transition to Non-Portal Approach

While we understand that perfect solutions don’t exist, the points mentioned above are not inconsequential, being enough to flag them here so that can be taken into account for similar future initiatives and also find additional inspiration by some insights for improvements below:

• Start as simply as possible, focusing on selecting and solving one use case at a time, but one use case at a time that contributes to all the previous problems solved and also enabling all the solutions to work together. For instance, aggregating and distributing startup events is a great place to start with as it is always happening and it is a problem on its own (improve audience-events matching).  
• Identify value first and then commit to scale - Build enough understanding and project base during the RFP design phase, making sure that those who suffer the problem are involved in the RFP design process, working collaboratively with the procurement team. Hackathons are becoming more and more usual as part of the procurement process to help narrow down key requirements and build initial concepts. MVP and agile developments are also very recommended in your efforts to create a path toward a successful use case. Some key elements that should be covered are: conceptualization and description of the use case, description of the use case strategy, user roles and processes (customers, partners, etc.), user needs, generating user value on the use case and user promises, identification, listing, textual documentation and preliminary user interface design (wireframes), data sharing contracts, preliminary definition of software and server architecture, phasing of digital implementation, tentative scheduling and draft call for tenders, sustainability model and preliminary structure and resourcing plan for the use case to be implemented
• Once the use case is selected, the requirements of the technological architecture should be sized according to the complexity of the use case while at the same time it is able and ready to scale up and evolve without needing changing any other underlying technologies we started with.
• Open standards and modern and mature open source based technologies and languages for data (Ie GraphQL) developed for the purpose.
• Adding more “platforms, portals and applications” with siloed databases approach, does not fix the connectivity problem, as the problem is at the data connectivity level between all these applications. It’s not that the information would not exist or about missing or wrong applications per se, it’s often about manual and/or non sustainable strategy and solution that is applied in projects supporting an ecosystem to increase connectedness. Ie people manually collecting and sharing data between applications.
• Follow the data journey - Focus on transactions and interactions between the users and services: collect data, organize data, distribute data, reach users where they already are, match information based on user profiles.
• Ecosystem account for individuals and teams are at the core of ecosystem interoperability as it enables the interconnection between multiple people, organizations, platforms and data, where the interaction is actually happening, while also making sure that data is in possession and controlled by its rightful owners, whether they are individuals and/or entities
• Personalized ecosystem window - focus on data aggregation and distribution to get accurately personalized information to the exact user needs and profile delivered to you every time while anticipating what is needed next

Ecosystems have a long way to go to activate this digital transition for ecosystem orchestration but it is definitely the right approach. However the decisions should have been made five years ago. We just have to look at when other industries like finance, telecom, healthcare, transportation, etc. started and how they are unlocking innovative cross-functional solutions by enabling interoperability. 

This is the big void we are covering with ecosystemOS and I believe this is where we can best be in the world, helping ecosystem builders and operators to design, develop and deploy use case driven technology solutions, step by step, to enable interoperability and information exchange within and between ecosystems to help them make quick, secure and efficient decisions.

This is already happening. If you want to take this hands-on post to the next level, feel free to reach out to organize a discovery session to answer your critical questions, guiding your team to explore the most feasible scenarios to get started, preparing your team towards the design phase and building initial prototypes.