So, we always assign proper timeslots to moments of confrontation, because it’s where the good ideas and smart solutions come from: the Platform Design Toolkit methodology is a catalyzer for this emerging value coming from the attendees, i.e. from the ecosystem, as they are definitely part of it.

That’s why, when we design our interventions, we always put in the first place the experience we are offering to the audience: our focus is not on the framework, it’s on the people.

So, properly designing Platform Design Toolkit powered live or remote experiences is also part of our skills. This post will offer you some ideas on how to design large scale workshops.

The Phases of Platform Design

When we work with organizations and individuals, we always refer to the following schema to organize logically the phases of our intervention:

The phases of Platform Design

In the Exploration phase, we give tools and a method to analyze the ecosystem, find the best opportunities for platform strategies and understand how the players and resources are distributed in the existing value chains. Then, we offer a guided flow to transform the value chains into platform-oriented value chains and identify valuable entry points for your strategy;

In the Design phase, through our Platform Design toolkit, we offer a guided methodology to design your strategy in supporting the ecosystem and leverage the value creation within it;

The Validation phase comes from the best practices set in the lean and startup thinking, but we’ve extended them to validate the ecosystem-potential fit and then the Platform-potential fit;

The Growth hacking is about understanding the Platform and Ecosystem features and metrics and how they impact on the critical mass and how long does it take to reach it.

In this post, we will focus on the first two stages, the Exploration and the Design properly said. The Validation&Prototyping and the Growth Hacking parts are always specific to the strategic design outcome and it’s not suggested to schematize them into fixed procedures.

Multiple teams, multiple projects

When you are preparing for a workshop with multiple teams (so, a large number of people), you typically fall into two cases:

• Many people / Many design contexts: each team is working on a different project brief, to be accelerated with Platform Design Toolkit. This is the standard case that happens in our public or private Masterclasses for example.
• A large team working on one strategic platformization challenge: a large group that can be broke down to multiple teams (as a rule of thumb we try to work with groups that are smaller than five to avoid having people defocusing during the design). This is the typical situation when we work on one strategic project, but trying to leverage on a large scale collective intelligence often also including ecosystem’s representatives.

If you fall into the first case, you wouldn’t be in trouble since every single team will follow the Platform Design Toolkit methodology independently and apply it to the project it’s working on. In this situation, you can rely on the standard logic flow offered by the Toolkit’s Exploration Guide and User Guide, each team will go through the Exploration phase and the Design phase on its own.

Photo by Yoko Correia Nishimiya on Unsplash

In both cases, a key idea is to benefit from the cross-fertilizing collective intelligence you have in the room, to ask teams to check another team’s project often and to give mutual feedback.

One approach could be to split the flow into four blocks: the exploration, the mapping and portraying of entities and roles, the design of the two engines — transaction and learning — and the Platform experience design, and stimulate a collaborative exchanges after each of these blocks.

In every collaborative exchange, you shall pair two teams together (we often change the pairs at any exchange, again to nurture diversity and avoid biased opinions), then one team explains what it has done so far and the other team reacts with findings and insights on what they’ve listened. The first team — that was explaining the project — can later iterate on the insights and improve the design. After this interaction is done, the two teams simply switch roles — presenter and listener — and repeat.

This exchange is really valuable since it’s acting as an implicit in-room simulation of a validation process: an external team that wasn’t aware of all the reasoning behind the design choices, will quickly give to the presenting team the assessment on what is clear and reasonable, what can be maybe wrong or not developed enough, and especially if in the external team someone can embody one of the entities/roles considered in the design, this is a good validation according to the lean startup paradigm we always support (“Get out of the building!”).

At the end of the design process, you could also propose to all the teams to have a gallery walk, i.e. to take the proper time to walk beside the canvases (a good idea is to hang them on the wall, respecting the ideal logic flow) and look at them sharing after the insights and relevant information they captured. In this way, every team can gain awareness on the quality of the job they’ve done and learn from other perspectives, and have material to re-iterate the design to improve it.

Multiple teams, a single project

This is definitely the most complex context, and it’s the main purpose we set for this article.

If you have a limited number of teams and people, you can always let each team work on the same brief to allow for a broader generative design, and schedule a converging moment at the end of the process to analyze the differences or the similarities in the design. You can also ask the teams to work on collaborative exchanges in a differential way, i.e. to let them track and write on notes the different perspectives that emerged during the confrontations between two different teams and their points of view.

Here, the “problem” arises when defining the meaning of “limited number of teams”, since it’s very discretional and depends on many factors. The level of maturity and expertise of the people, their skin in the game, their outlook on the strategy and on the ecosystem, but also their role in the project. If you are delivering the event to teams with very similar composition and “level of understanding of the context”, in our experience a differential design approach can work if you have two or three teams, not more.

If you have heterogeneous teams with different roles — executives, technical, marketing, design, etc — problems will start to become evident since the multiplicity of so many different approaches will be too divergent and in the collaborative exchanges, teams will never get to an agreement.

The good news is that you can ask each team to focus on its specific domain of knowledge and start the exploration and design sprint by helping it leverage on the specific competencies they have, and this is a good method to have a very detailed and comprehensive final design, where the teams could explore many aspects of the project in a single sprint.

If you fall under this case, a golden rule comes from the best practices of service design: do you remember the service design diamond?

Every single step will have a first divergent phase where you will leverage the collective intelligence in the room to generate ideas, map in detail what is happening or trying to happen in the ecosystem, portrait the entities and roles, think to channels and services the platform can offer. Then, a converging moment will follow, and your responsibility as a facilitator will be to keep everyone on the same page in the sprint and guide the teams to find a shared and agreed outcome for each design step.

Let’s go through the process and see which is the best approach for each step.

Ecosystem Scan — Existing Experiences

The purpose of this step, that belongs to our Platform Opportunity Exploration Toolkit, is to track all the experiences that the entities or roles interacting in the ecosystem are having at present, with the purpose of identifying who are the most important players in the context, which actions they are doing, if they are intermediated by brokers or aggregators and which are the infrastructural components they are relying on.

Divergent phase. In this exploratory step, the more teams you have, the better it is: you can simply ask each team to list the experiences they see in the ecosystem, write them on common space, sort, cluster or crash the similar ones and then assign some experiences to every team to have them mapped in detail. As a result, you will have a “wall” — either physical or virtual, depending on if you’re running a live or remote event, it doesn’t change too much — with a detailed picture of all the relevant experiences happening in the given context. In this phase you can also cluster the similar experiences and consider only one per group, or ask the participants to vote — DOT Voting is a best practice — the main ones, that will be expanded in the next phases of the design.

Convergent phase. At this stage, you need to help teams to converge to the most relevant players — entities or roles — , to identify the dominant intermediaries or other platforms, and every team should be aware of the full picture that has emerged. So, a good approach is to propose a speak and listen moment, where each team appoints a speaker who will explain the mapped experiences to the other attendees — maybe in a plenary session — in a short time. If you have similar experiences explored by different groups, you can also go for a peer exchange: you pair the two teams together, each team in turn explains the activity done to the other team and the latter gives feedback, and then they switch.

Wardley Maps — Value Chain analysis

We are still in the exploration of the opportunities stage, so we will ask each team to carry on the translation of the experiences they have found, into the value chain map canvas.

Divergent phase. We are highly interested here in having teams generate as many ideas as they can. If translating the experience(s) into a Wardley Map can be quite mechanical, each team can cast different hypothesis when unbundling the actions taken by the entities into more granular actions, or when considering the evolution stage of peer consumers or peer producers, and assets. Also, when evaluating technical aspects in the value chain, or when identifying the assets that can be valuable for the organization in the existing value chain, the different skills and knowledge of people can be very precious to reach a solid design. This aspect becomes more important when the teams consider the Platform Plays application to transform the current value chain into the final target Platform value chain: here having many perspectives in the audience is pure gold. Let the teams be creative.

Convergent phase. Each team can write on post-its the main insights they found when applying the Platform Plays to the value chains, and stick them close to the canvases. Then, all the teams can do a gallery walk, read the insights and evaluate the canvases and react to the insights, or share what they did. If you’re not sure that all the attendees are feeling comfortable in sharing their opinion, you can organize a Fishbowl so that everyone has the same chances to express her considerations and, most importantly, this technique teaches how to actively listen, especially if the feedback session is using the I Like-I Wish-What if frame.

Ecosystem Canvas — Mapping the ecosystem

At the end of the exploration of opportunities phase, the teams will have already a probably long list of entities or roles active in the ecosystem. So, your challenge here as a facilitator is to find how you can keep this diversity as long as you can, without having people feel lost in this complexity.

Divergent phase. The suggestion we can give here is to split the large audience into subgroups, maybe according to their role or competence in the organization, and let each team map the ecosystem according to their prevalent focus or point of view. Examples could be B2B versus B2C, or any other business types (B2B2C, D2C, etc.), or a more technical point of view, or simply by letting teams cluster the entities according to different roles. This possibility is in our opinion very interesting, since the choice of a role label is open to a certain degree of subjectivity and is one of the keys to the disobedience every good platform should offer to the ecosystem. If you also consider that the distinction, in real platforms, between producers and consumers is more and more often very blurred, and the same entity can change role and type (consumers or producers of value) dynamically in the same ecosystem and participate in multi-sided interactions, you see how much value there is in having multiple teams mapping the ecosystem from different starting points.

Convergent phase. The converging moment in this step can be done in plenary. You can ask teams to list all the entities or roles they found on a whiteboard, and let them re-clustering the similar ones, or simply voting which entities are according to the audience the most important. At this moment you can also check if the maps are leading to different project briefs: in case the participants expressed the will to carry on the different perspectives identified, you can fall back into the first case “multiple teams, multiple projects”. If not, and the project is confirmed as unique, then you need to get to an agreed and unique map of the ecosystem. After the clusterization of similar entities, you can ask the teams to have a dot voting round to pick the five most relevant entities.

Ecosystem Entity-Role Portraits

In this step, the objective is to deeply portrait all the entities, so that you will have useful information for the next steps. The EEP canvas is really central in our design toolkit since we use it to provide elements for the two engines and for the final reality check on the “pulling resonance” of the Platform Experiences, and the deeper it is filled up by the attendees, the better is for the design outcome.

Divergent phase. The divergent phase is pretty easy. Depending on how many entities and how many teams you have, you can assign every single entity — role to a different team or, if the number is not matching, you can split the teams into smaller subteams and/or let them work in two on the same entity, especially if this entity is very relevant. As an example, let’s imagine you have 4 entities in the ecosystem canvas and you have 5 teams, you can have two teams working on the main entity. Or if you have 5 entities and 4 teams, you can split the teams — all or some of them — to cover the portraiting activity. We suggest you write the entity — roles names on each EEP Canvas and let the teams to freely choose the entity they prefer without forcing the choice: the latter is always a bad idea because it can generate blocks and uncomfortable feelings in some of the attendees.

Convergent phase. It’s really mandatory that all the attendees are deeply aware of the EEP Portraits after this stage. So, you will propose techniques to let everyone read and digest the information on the canvases and share insights or feedback. These techniques are:

• a gallery walk, followed by an insight/feedback sharing, maybe through sticky notes and not verbally (more time consuming);
• a speak and listen peer to peer exchange, in plenary;
• a fishbowl, more time consuming but really effective also as an experience for your guests;

If needed, at the end of the collaborative exchange, please schedule a re-iteration to let teams integrate the comments received.

The Motivation Matrix

This canvas, so simple and yet so relevant to harvest the unexpressed potential flowing (or trying to) in an ecosystem, seems to be born for parallelized work on it.

Divergent phase. You can split the audience into three sub-groups (or in six, if the number of attendees is very large: you shouldn’t allow teams of more than 5 people each), then one group will work on the lower section, the second team will work on the diagonal of the Motivation Matrix, while the third team will work on the upper part, see the picture for a better understanding. They can work on the same canvas, or on three different canvases and then you will help them consolidate everything on a single board.

If you have six teams, you can let 3 teams work on one MM and the other three on another Matrix.

Convergent phase. You choose one of the three Motivation Matrixes, that will become the main one. The team that worked on that part, just explains the content of the cells to the other two teams. Then, the team that worked on the lower part will move all the notes from their board to the main board, and explain the elements when moving them. The third team will do the same.

If you had six teams, the two subgroups of three teams do like we’ve just described, and then you will need another collaborative exchange session, for instance the speak and listen, to work on the differential design analysis.

The Transactions Board

Transactions are easily assignable to different teams since you’re mapping the key relationships and exploring them. The tricky part is how to choose the core system and the number of core entities and core relationships.

Divergent phase. If you have three core entities, you will find a maximum of three key relationships. If you have five core entities, the number of key relationships can go up to ten. So, if you have a corresponding number of teams or you can split the participants to a matching number of teams, you’re done, otherwise you can assign two or three relationships to each team. If you want to reduce the number of key relationships to be explored, especially if your design is considering all the five entities, you can ask the attendees to vote the three or four most relevant (i.e. one per team).

Convergent phase. The transaction boards can be moved together in the same space, and the teams just need to look at them through a gallery walk or a speak and listen. Feedback can be given in case some transactions are not clear or incomplete, or on how to re-design channels to reduce the transaction costs. Typically, it just takes 2 or 3′ for a team to explain a board, then leave at least 10 minutes to exchange feedback.

The Learning Engine Canvas

Luckily, also the Learning engine Canvas is very flexible and it’s suited to be parallelized. Each horizontal row is showing the potential growth of a core entity and each team can be assigned to explore the entity’s evolutionary journey. You will need to pay attention when there could be transformations of entities into different entities or roles: these are tracked on the vertical axis, so if you parallelize the activity, this part can be done only at the end.

Divergent phase. Depending on how many entities — roles you mapped and how many teams you have, you can split the audience into two or three subgroups and let them map the learning paths of all the core entities, and then you will cope with highlighting the differential design outcomes of this highly generative session after. Or, alternatively, you can assign one entity to a single group, that will work only on a horizontal stripe.

Convergent phase. If you have only two Learning Engine canvases, you can arrange for a standard collaborative exchange. If your teams worked on the single stripes, then you need to recompose the board by moving all the stripes together in the same area. While doing this, each team should explain what it has done to the other teams. In the end, you should give enough time to the teams to understand if some of the entities can have a transformative evolution in the vertical axis, i.e. becoming a different role or entity.

The Platform Experience Canvas

This canvas is probably the most important since it consolidates all the design outputs from the previous steps into a final one, ready for the validation of assumptions and for the implementation of a prototype. Your objective here as a Platform Design Facilitator is to have as many experiences as the participants can think of, since having many Platform Experiences drafted can offer multiple ways for monetizing the Platform Strategy and can offer different pulling experiences to multiple sides of the ecosystem.

Divergent phase. Each PEC can be focused on a key relationship, so you can split the teams as you did for the Transactions Board. Another option is that different teams can work on the same key relationship, but maybe changing the point of view, i.e. the core entity. You will have the same action chain, that involves the same entities, but the different perspectives will enrich the considerations on touchpoints, services, and actions performed by the platform itself and by the peers in the ecosystem, giving birth to a different experience and potentially to a different business model.

Convergent phase. Each PEC is telling a story in itself, so the only good advice here is that everyone ideally in the room must understand completely the Platform Experiences that have been designed by all the teams. So be sure to have enough time for peer exchange and for a feedback exchange. Being this part so important for the general satisfaction of the working teams, it’s better if the teams can have time to re-iterate on the experiences after they got the considerations from other teams.

Conclusion

So, we hope you’ve enjoyed this highly operative post, based on our long experience in running complex workshops in a global context. Recently we’ve raised the bar by launching large scale online public masterclasses and Bootcamps. If you’re interested or if you like to share your experience, we would love to hear from you. On this page, you can find the latest news on our public events, or you can contact us for private tailor made interventions here.