Hi everyone! 👋

Reserva tu plaza

I’m starting a new project to help more people on their engineering strategy journey. Well, they are kind of two projects.

Wardley Mapping en Español cohort

A dedicated cohort course in Spanish for the Spanish-speaking community for an in depth learning on Wardley Mapping applied to Software Companies facing high stake business challenge.

A brief description of Wardley Mapping benefits in Spanish.

Los mapas de Wardley nos traen diferentes beneficios:

👉 Clarificar el pensamiento: ¿Qué cosas importan? ¿Cómo funciona todo? ¿Y qué es lo que quiero?

👉 Eliminar la desalineación: ¿Dónde estoy siendo poco claro con los demás, y ellos conmigo?

👉 Evite errores embarazosos: ¿Cuáles son las cosas obvias que debo saber y hacer?

👉 Acabar con el trabajo que no aporta valor: ¿Dónde estamos malgastando nuestro tiempo, energía y esfuerzo?

👉 Derrotar a las palabras de moda: ¿Cómo puedo crear significado donde no lo hay?

👉 Crear claridad de propósito: ¿Cómo puedo crear un entorno que otros querrán aportar?

During 6 weeks, we will have 6 interactive live sessions of 2h each plus more than 13 in-depth lessons to go from 0 to your first strategy based on high situational awareness.

Because you are part of this community, you have a 20% discount using the code MAPA20. If you’re a paid subscriber, DM me for a 25% discount.

If you still have doubts if this course is for you, leave a comment to the post or DM.

Cohort based courses

I found the cohort based courses to have a lot of benefits:

• Active hands-on learning: Course built on live workshops and hands-on projects.

• Interactive and project-based: Interacting with other learners through breakout rooms and project teams.

• Learn with a cohort of peers: A community of like-minded people who want to learn and grow alongside you.

If you want me to do specific cohort courses on topics like Engineering Strategy core concepts and in practice, Domain-Driven Design, Team Topologies, Wardley Mapping, or whatever you consider. Take 1 min to answer this survey. 👇

Show your interest here!

Why starting in Spanish?

Ben Mosior did an awesome job sharing about Wardley Mapping in English, I learned a lot from him.

I found that the Spanish-speaking community didn’t have many resources available about Wardley Mapping, and I want to change that!

At the same time, cohort based courses on Wardley Mapping isn’t that common, or at least I didn’t find any.

The good thing about cohort based learning is that it is interactive, you connect with like-minded people, and we explore multiple contexts in the same cohort.

That’s why I consider running an English edition if enough people are interested!

YouTube channel

I love to write to help me understand better the concepts, it helps me organize my mind. I love to teach courses, it helps me connect with awesome people facing hard challenges, and learn together on specific real life scenarios.

Now, I want to explore how video content on hard concepts such as engineering strategy can bring to me as a creator, and to you as an engineering strategist.

That’s why I started a Wardley Mapping playlist in Spanish first. I’m adding some shorter videos based on the cohort course so you can get a feeling on how the recorded videos in the course looks like.

I will publish content in Spanish and English on similar content I write in my newsletter.

Subscribe to YouTube

Wardley Mapping is provided courtesy of Simon Wardley and licensed Creative Commons Attribution Share-Alike.

1. The users
2. Their needs
3. Value chain
4. Evolution
5. Factorial’s gameplay
5.1. Becoming an ecosystem
5.2. Jobs to be done
5.3. Efficiency for innovation

⚠️Disclaimer. All the content, assumptions, claims, and so on I do on Factorial Product are my own interpretation, and it doesn’t represent the company’s reality. This post is an open practice on Wardley Mapping to understand how more products are relevant to map.

Factorial is a product/company quite known in Barcelona, Spain, as they have their headquarters here, and they run a quite famous podcast in Spanish, Podcast de Itnig.

They are an all-in-one HR SaaS for SME that intend to automate everything HR, from time management, to talent from hiring to performance review, via finance such as payroll, and employee expenses.

I used it during 2020-2022 when I was Engineering Manager.

What I want to say with this is that their business domain is quite huge and complex. Which makes it a perfect product to explore using Wardley Mapping.

The other reason why I chose Factorial is that we have been experiencing several changes in the tech industry compared with the Zero interest-rate policy, ZIRP for short, period.

We are seeing less rotation, harder to find competing job offers for software engineers, and other roles within the tech industry, a push for efficiency, and that translates pressure for HR software to adapt to the new context where focus moves from attracting and keeping talent, to employee efficiency, followed by policies like Return To Office, RTO for short.

You can see more in the following post about the ZIRP, and the change in the industry.

The Pragmatic Engineer

What is Old is New Again

👋 Hi, this is Gergely. I give one conference talk per year: this was the one for 2024. It’s my best attempt to summarize the sudden changes across the tech industry and what they will mean for the next few years of software engineering…

Read more

2 years ago · 361 likes · 2 comments · Gergely Orosz

1. The users

By looking at the top menu items, we can already tell that Factorial is a huge product serving a variety of users and industries. I’m not able to map everything, therefore I’m focusing on the Technology industry needs because that’s the ones I’m more familiar with, plus it’s the purposes of this post.

Based on the menu item by Role, we can assume there are three users to map.

2. Their needs

When I started to understand the user needs, I noticed that I might mapped it wrong. The landing page lists three roles, but I think this is a marketing acquisition decision to attract the main buyer personas that convert the most.

I think their users looks more like this:

I merged CEO and HR managers because their expectations right now much aligned. The landing page says that HR Manager to streamline administrative tasks and focus on team development, and CEO to optimize, reduce structural costs, and boost the business.

Which long story short, it is about efficiency.

I believe that the role of people management and growth (at number of employees, and employees career) isn’t the primary business focus anymore. I’m basing the article with this assumption.

The ultimate value proposition is about to spend less time on manual tasks related to HR and dedicate that time to productive tasks, those that aim to generate revenue. From this perspective, I will map the user needs.

Furthermore, I made explicit the needs of Managers, and Employees. You cannot streamline administrative tasks, nor optimize structural costs without reducing the gross time spend where you have more people, in non-HR roles.

So, I consider factorial is achieving their mission by providing an all-in-one solution targeting HR managers/CEO as buyer personas, and then rolling it out to the product users such as HR managers, Managers like Tech Leads, and Employees.

In order for this to work, they have to delight those three users.

3. Value chain

Factorial’s pricing page is the full representation of the components needed to fulfill those user needs. You can see this within the application after registering, I didn’t find it public.

By looking at the value chain, we can see how much features are related to Talent Management, involving the different users. In order to understand more of that area, we should do another map only zooming into that area, but I leave that for the reader to do. I don't to spoiler all Wardley Maps we could do on Factorial’s business landscape.

4. Evolution

As I was adding the evolution axis, I noticed that almost all the Factorial’s capabilities are in the product or commodity space.

Well known client needs to be integrated in one place.

We can even see some of the commodity products being included in the pricing space and not being optional, while other’s that are more in the product area being an add-on to the monthly basis subscription.

After trying the Factorial’s product thanks to the free trial, I had the impression that several capabilities are self-contained, not depending on other capabilities other than shared concepts such as employee, company, and alike. Everything you need to do on a capability, it is under the same tab/URL.

I’m not sure if they are reusing code, copy-pasting, creating shared libraries, or having subset shared capabilities as a Factorial’s platform focused on common user facing needs. I’m having this guess due to the common UX, that requires a lot of shared building components to be sure that the app behaves the same, combined with the shared language on what some key concepts mean, like employee, company, etc.

5. Factorial’s gameplay

The beginning of the post I assumed I could describe how post-ZIRP affects SaaS HR solutions for SME market such as Factorial.

Even though I cannot share a 1:1 relationship, I think I can describe three main factors that could represent a response to a market that needs to be do the same with less/do more with the same. For both, clients and providers.

1. Becoming an ecosystem.
   Factorial cannot serve an hetergeneous market by itself. So, it invests on becoming an ecosystem where others can build on top of.

2. Rethinking the UX of HR needs with Jobs to be done.
   If clients needs to have an even more efficient HR department, and all the related management tasks, they have to stop investing on local feature optimizations, and think the E2E HR user journey, and optimize those jobs to be done.

3. Efficiency for innovation.
   For internal development, decrease the cost of solving new critical user needs by creating an Internal Product Platform. Instead of requiring more product-tech teams to keep delivering/removing features, reduce the cost of creating new capabilities by having a compelling and thin product platform for the main use cases.

5.1. Becoming an ecosystem

There’s a moment when you cannot solve a huge variety of user needs, and you need to opt for another approach. Allow external developers to solve those user needs for you in exchange for an ecosystem they can sell their products/integrations to.

I saw it quite clearly in the Integrations page.

The ecosystem gameplay can be expressed quite clearly as a Wardley Map. We have 3 users:

• Factorial. Wants to create an ecosystem for others to innovate on top of.

• Factorial customers. Want to adapt/customize more Factorial to adapt to their needs.

• Factorial partners/developers. Want to publish integrations, to either serve better their customers within the Factorial’s ecosystem, or obtain new users thanks to Factorial’s ecosystem.

This approach, which means releasing an API where others can build on, will support Factorial in the next way. Factorial will be able to add metadata on how the different set of integrations behave, and detect future user needs that they want to invest on.

5.2. Jobs to be done

I recall a Podcast where they were sharing some of these insights, but I’m guessing the reasons, and the approach. Remember, I’m exploring as an external viewer.

As up to today, Factorial’s user needs are quite self-contained. Which means that they solve one thing, like Time tracking. During a podcast, I recall that they want to create a new user experience that go beyond of self-contained features, to Jobs To Be done. Or how I understand it, instead of focusing on needs == capabilities, moving into needs ==> a set of capabilities well interconnected.

My bet here is that Factorial is investing in a better UX, moving from commodity capabilities for well-known user needs, to reinvent how HR is doing their job to make their job even more efficient.

The guess here is that they cannot make the HR processes more efficient within the same capability, and they need to move to make the Job To Be Done more efficient to have huge impact. Moving from local optimizations, to big picture optimizations for their clients.

The approach might be AI Agents.

Factorial partnered with Microsoft Azure OpenAI during early 2024. There is a high chance that this Jobs to be done will be driven by AI agents touching a broad set of capabilities.

5.3. Efficiency for innovation. Platform?

I recall a Podcast where they were sharing some of these insights, but I’m guessing the reasons, and the approach. Remember, I’m exploring as an external viewer.

LinkedIn says there are 1.666 associated members, which I can assume between 300 and 400 works in product-technology.

Sales, ops, business development, and customer-success are around 800.

Factorial focuses on SMEs, but the amount of people in sales, ops, and customer-success suggests that:

• They are approaching an upper market, maybe more mid-market.

• The platform isn’t as self-served as I expected, and it might require a high touch engagement model. That’s due to the emphasis on customer success service.

Combining the point 5.1. becoming an ecosystem, adding new capabilities, and addressing new and existing user-needs shouldn’t require duplicating the engineering team. The size is already significant, and the benefit of creating new teams isn’t lineal to ROI.

The amount of customers, and the product size should allow Factorial to have enough data to invest in safe bets, and have great Go-To-Markets to deploy new products to existing customers that those needs have been already detected.

So, instead of creating new full features by new teams, it can be interesting to create a kind of Internal Product Platform, using the Team Topologies Term of Thin Platform As a Service.

The Internal Product Platform (IPP) should act as a set of common capabilities to help product teams to deliver products to address known user needs, or explore new ones.

IPPs enables you to:

• Make the product more stable, as you make high-used, high-dependency, use cases stable.

• Create a shared language among all teams on key concepts, and the cost of integrating those concepts instead of build-it becomes worth in the mid, long term.

I recall last time I did an IPP to make some sensible decisions such as:

• IPP team members were part of product teams, and understood the user problems.

• IPP team members had the right product skills such as explore user needs, talk to customers, pragmatic, soft skills, and familiar with Team Topologies to be sure they were creating the thinnest viable platform, and not a big one.

• Facilitating the adoption of the platform by use case as soon as they were available, reducing the risk of platform adoption, and be sure we were building the right thing that solves business, user, and product-engineering needs.

A good way to understand the teams context, and where to start investing is to understand the socio-technical system from a team cogntive load perspective following the Team Topologies guidance.

We are building Teamperature to help organizations to make conscious decisions taking into account teams cognitive load, and track the impact overtime. Check it out!

That’s it! I hope you enjoyed the post as I did writting it. Love to hear your feedback, and know which product you want me to Wardley Map next, leave a comment.

Leave a comment

If you are from Factorial, and you want to help me to fix some things that are wrong, and collaborate on making a more accurate article, feel free to reach me via DM, at LinkedIn, or at hello at aleixmorgadas.dev. Love to chat! 🙌

I’m helping organizations to design and execute their engineering strategy. If do you think I can help you, let’s chat!

Schedule a 30min chat

1. The users
2. Their needs
3. Value chain
4. Evolution
5. Sociotechnical system
6. Buffer’s gameplay
6.1. Expanding into revenue
6.2. Channels expansion gameplay
6.3. Ecosystem (new thanks to Amanda from Buffer clarifications)

⚠️Disclaimer. All the content, assumptions, claims, and so on I do on Buffer are my own interpretation, and it doesn’t represent the company’s reality. This post is an open practice on Wardley Mapping for PLG products to understand how more open products are easier to map compared to more closed ones.

🎉Update 16th December 2024: Amanda Marochko, Staff Product Manager at Buffer, reached me after reading the post, and share clarified in some areas that I was mistaken/had the wrong information. Amanda, thank you very much for your time!

I will mark the previous info and the new info so you know the difference before and after the conversation. Plus the Amanda’s clarifications. The words are mine, and might not be 100% accurate due to making a summary of the conversation.

I use Buffer to schedule some of my content for Bluesky and LinkedIn, and I wanted to learn more about this product because it has several interesting traits.

• Open Company. I can find all relevant information at https://buffer.com/open.

• Podcast Interviews. I can learn more about their decisions at interviews.

  • R072 - Cultura de producto en Buffer, con Mike San Román

  • Defaulting to Transparency with Joel Gascoigne

• Product-led Growth approach. Which helps me identify the customer, and their needs easier as I don’t need to speak to sales.

1. The users

Learning which is their customer is quite straight forward using key sections of any landing page.

• The testimonials.

• The pricing page.

• Use cases.

Buffer has the first two.

Based on these two sections, we can determine that the users are:

• Individual content creators due to the Essentials plans.

• Marketing/content teams.

Amanda’s clarification: You are right. We have these two user personas, we have aimed to attract SME businesses, but we found out that individual content creators, such as thought leaders as you, are the main user persona that we are attracting. More focus on them will be put into 2025.

2. Their needs

Understanding the user needs is quite straight forward for individual content creators out of the Tools navbar menu.

On the other hand, content team owner can be inferred from the pricing page, but I tried the organization features to be sure those are the main ones for teams. Thanks to the free trial, I was able to verify those needs.

3. Value chain

Buffer has a quite interesting approach on the subdomains, almost a subdomain per navbar item.

Create and Publish sharing the same subdomain can determine a legacy constrain due to the company probably started with a monolith providing creation and publishing posts, and later-on has evolved into their own products, but the code probably being coupled kept them together.

At components level, we can identify few, but they vary a lot depending on the channel and post type. I consider them to be like a pipeline, where we have several components evolved differently

Let’s explore it directly into the Wardley Map with the evolution.

Amanda’s clarification: Yes, the subdomain approach is a legacy decision when we had a subproduct approach. Right now, we are considering Buffer as a one product to have a unique experience. We are working on this for 2025.

4. Evolution

I identified some key components like Ideas, Posts, and Reports. Those looks like they have been a pillar for Buffer. When navigating the product, I could see how the channels influenced the post types, as well as the feature maturity beyond create and publish.

I could identify text and image posts to be well establish, and be part of cost of doing business, while video is part of the new offering. On the other hand, polls posts aren’t supported (AFAIK).

That’s why I create a pipeline for the Channels, where the channels that support more features are more evolved than the ones that aren’t that evolve like Bluesky. It has been interesting to find that Meta products, Facebook and Instagram, are quite evolved, but Threads don’t. The evolution Thread’s API could benefit Buffer to extend the use cases for Threads as well.

Other channels are keeping most of the API restricted to publish, and few are opening for analytics.

5. Sociotechnical system

By looking at LinkedIn, we can infer the amount of teams, and how that affects their domain structure.

I did this exercise after the Wardley Map, so, let’s see how by knowing the team size can help us identify which domain boundaries they could define, and how that can evolve in the future.

• Total: 226

• Operations: 58

• Engineering: 40

• Customer success: 27

• …

• Product management: 7

LinkedIn isn’t accurate on the numbers, but based on them, we can assume Buffer has around 5-7 product-engineering teams.

Amanda’s clarification: This is the part of the post more wrong. We aren’t +200 people, we are 80 people company.

• Total: Around 80 people

• Operations: 5 people

• Engineering: 25-30 people

• Customer success: 27 people

• People department: 4 people

• Marketing: 15 people.

With 4 product-engineering teams:

• Apps, channels, and platform.

• Consumer experience.

• Audience engagement.

• (another I don’t remember the name) 😅

They leverage multiple providers, such us:

• A lot of customer success tooling like HelpScout, Klaus, Pendo, Retool for internal dashboards probably

• All connected with tools like Fivetran.

Even though it looks like they have the approach of buying off the shelf as much as possible, they also do custom build solutions. Those are made with:

• Web and API: ReactJS, NodeJS, Typescript PHP, GraphQL and MongoDB

• iOS: Swift, SwiftUI & Objective C

• Android: Kotlin, Java and Jetpack Compose for Android

• Infrastructure : AWS, Kubernetes, Datadog, Terraform, Docker, Github Actions

I didn’t identify the need of providing an iOS or Android app.

Regardless of that, it seems like they have a full-stack mindset, and everyone is expected to help everywhere when possible.

Because of the usage of K8s, and the stack, and the URL composition, it is quite possible that they are using a microservice architecture.

It doesn’t look like they have a platform team, even though a candidate can be the channels component.

The channels component needs to provide connect to all the social networks, and that would require a unified API, but at the end, and because of the post topology, encapsulating that can be complex. So, I’m quite sure some common stuff like Authentication, OAuth2, and alike are shared components of that microservice, but then each channel has its own implementation, and that’s exposed to the different components in some degree.

I believe the teams aren’t per user need/domain.

I believe that the teams might have some degree of influence based on the product structure per subdomain, but I think the teams work on domains that overlap, and they share some components, to deliver product increments.

Those shared user journeys, or shared components, are beyond the channels. They also have the components of:

• Organization, user management, and permissions.

• Payments processing.

• Landing page.

• Internal tools for customer success.

• Internal data tools for high visibility and decision-making due to the product-led growth approach, and the need of optimizing the right user funnels to make it as low touch as possible.

6. Buffer’s gameplay

Buffer biggest constrain is the social-network API’s dependency. As long as social networks don’t support posts formats or key APIs for engagement/analytics, they are unable to offer a value add on the new features such as analyze and engage.

The bet on Buffer’s AI is key for the creation/idea phase, and also as engagement.

If they are able to augment the personal brand by, instead of generating out of the blue content, creating tailored content based on previous posts, understanding the tone, the audience, and so on, it can be very beneficial.

Combining Buffer’s AI with:

• Current posts to understand the brand tone.

• Understand which posts brought more engagement.

• Provide insights on industry trends…

can be awesome.

6.1. Expanding into revenue gameplay

Engaging and growing the social networks might not be enough, and the customers need to understand if that converts to revenue.

Right now, Buffer is solving the content creation pain. If they are able to extend that into understanding revenue via Shopify APIs for example, it could provide in-app insights on which pots provided bigger ROI.

That bet would require bigger understanding of their user base, and start by a concert segment of their user base.

This can position Buffer’s as a NoCode application from building an audience, to creating a sustainable business guided by data.

Amanda’s clarification: We won’t do that specifically due to the risks you are mentioning. Expanding into this area is a huge bet, instead, we will do (See point 6.3. Ecosystem).

6.2. Channels expansion gameplay

Keep integrating with other places where content creators audiences could be, such as Quora, Redit, WhatsApp channels, Telegram Channels, …

It is a well understood gameplay by Buffer’s team, and probably following the same strategy in terms of go-to-market, engineering, product, etc.

Amanda’s notes: Yes, being the first ones to adopt new APIs for channels to expand the channels feature is a strategy we keep. That’s why we are close to those channels to be the first ones to implement.

6.3. Ecosystem

This point is thanks to Amanda’s clarification. Thank you for allowing me to share this insightful strategy with my readers 🙌

Betting on new lines of business, and user needs, have a high risk.

Instead of betting on certain new user needs, and limiting the innovation. Buffer’s 2025 strategy is focused on creating an ecosystem to help other’s build on top of Buffer.

In order to do so, they are working on three main “new” components:

• Buffer’s external/public API to access all the components like channels, and so on that I mapped previously.

• Buffer’s marketplace to help Developers publish their products, let’s call them power-ups following the Trello’s terms, and Buffer content creators customers to find new ways to engage, and reach a bigger audience.

• Buffer’s new pricing model to support the marketplace approach.

If you are from Buffer, drop me an email, a comment, or a DM, to know much right and wrong I was!

Thank you a lot for reading this post 😄.

I love to read your feedback and opinions to help me improve. You can DM at my LinkedIn or just leave a comment using the following links:

• 😍 Awesome

• 😐 Okey

• 😨 Bad

Leave in the comments another product that you want me to Wardley Map.

Leave a comment

I assumed I knew my users and their needs.

After some years practicing Wardley Mapping, I realized that the phase 1 of doctrine, stop self-destructive behavior, is way harder than I thought.

I assumed that I knew about the user and their needs because I was working on well established companies that already had product market fit (PMF).

When I moved back to startups pre-product market fit, I just found that not having a “stable” anchor changed how I practiced Wardley Mapping. And having to discover which are my users and their needs changed how I mapped.

I’m currently building Teamperature, a B2B SaaS that enables organizations to assess their team cognitive load.

We are pre-PMF, which means that our users and their needs are based on bets and hypothesis. Any new learning can change rapidly the landscape and improve our situational awareness.

I found some interesting behaviors of mine and how I treat stable and unstable user needs. These behaviors appeared when I was part of a small startup during 2020, during 2023 while I was building Enabling Flow, and now with Teamperature.

The next map is a simplification of my experience building products to verify PMF.

First. I start building an MVP to verify our competitive advantage, and I usually start finding some early adopters. The MVP is messy and it only does one thing.

What happens next and after receiving some feedback, I start extending the MVP to fulfill a functional journey end-to-end, and those user needs often are well known. Things like invite my teammates, assign roles, email notifications, …

Then, my focus swifts from verifying the competitive advantage to provide self-served experience product. I always think it will take less time than it actually takes, and it starts to create a constraint of investment into the MVP itself.

At some point, and based on usage, it starts to seem that the initial hypothesis is verified, but it isn’t. It is just taking longer to verify the churn.

A critical metric to know if a product has reached product-market fit is retention and churn.

So, I realized that my behavior towards building a product to verify PMF is:

1. I start lean by only building the minimum to show a PoC about what is the product about and gain feedback.

2. I custom-build an MVP that only addresses the hypothesis user need.

3. I move into building those expected features that are preventing further product adoption.

4. I realize that I’m investing too much time on expected user needs rather than actually verifying the business hypothesis.

I can tell how much the map is moving towards the wrong direction. When I am gaining way more situational awareness on the expected user needs rather than the hypothesis user needs, I know I’m focusing on the wrong side of the map.

On the other hand, I also sense when investing on the wrong area creates inertia to change. If I invalidate the hypothesis, then it could mean that I also need to drop several things that are stable, like the expected user needs. Which it will increase my sunk cost fallacy.

So, investing on expected needs give me the unrealistic sense of stability and going in the right direction. Which indeed makes it way more risky.

Wardley Mapping the landscape helps me realize that I’m repeating this behavior and help me keep focused on what’s important. Validating the business hypothesis.

It forces me to:

• Challenge my assumptions.

• Know my users.

• Focus on user needs (the actual that will produce future ROI).

If you are using Wardley Mapping to understand your startup situation:

• Are you challenging enough if you know your user needs?

• What would happen if you actually verify that you aren’t addressing their actual needs?

• Are you focusing on the right part of your map?

• Are you using appropriate methods, or you are custom-building the wrong thing?

In case you want to share your wardley mapping situation and have a 30 min chat, you can schedule one using the following button.

Schedule a 30min Wardley Mapping session

Thank you a lot for reading this post 😄.

I love to read your feedback and opinions to help me improve. You can DM at my LinkedIn or just leave a comment using the following links:

• 😍 Awesome

• 😐 Okey

• 😨 Bad

⚠️ Aviso. Las conclusiones y contenido que publico sobre las empresas que mapeo son extractos de información pública y de mi interpretación de esta. Para nada tiene que ser una representación real de la empresa ni de su situación actual.

¿Qué es Wardley Mapping?

En este post asumo que ya conoces los Wardley Maps, pero en caso de que sea la primera vez que escuchas esta herramienta, te dejo algunos links para que puedas familiarizarte con ella. La mayoría de contenido está en inglés 🙏.

Hoy vamos a mapear Syra.Coffee

Una buena manera de practicar Wardley Mapping es por explorar dominios, industrias o empresas que no somos expertos, pero que somos usuarios.

Como buen consumidor del café de especialidad y cliente de Syra.Coffee, me ha parecido una buena manera de empezar esta serie de posts.

Historia de la compañía

• Nace en 2015 por su fundador Yassir Raïs.

• Democratizar el café de espacialidad.

• 3a era del café. Desde café de casa, a Starbucks, a café de especialidad.

• Cafeterías pequeñas de 30m² para llevar.

• Ha crecido hasta más de 40 cafeterías en al menos 8 ciudades.

¿Cómo vamos a mapear Syra.Coffee?

La mejor manera es entrevistando las personas clave de la empresa, en caso de Syra.Coffee es su fundador, Yassir Raïs. Pero por falta de tiempo y logística, optaremos escucharle hablar de su negocio mediante una entrevista de Itnig de hace unos 4 años.

A partir de la entrevista, podemos crear mapas de Wardley de como él comprende el valor de Syra.Coffee, y como ha ido adaptando su estrategia según iba aprendiendo.

La cadena de valor del café de especialidad - 2015

Durante la entrevista veo que se quiere invertir en la zona de custom-build por tres razones:

• Una alta calidad de café de especialidad.

• Una nueva experiencia de tomar café para llevar.

• Una fuerte marca que acompañe esa nueva experiencia de tomar café.

Datos estas apuestas, Yassir comenta que quiere ir de 0 a 100 entrevistas.

2019

Durante la entrevista menciona que se ha encontrado con varios cuellos de botella.

• Se han dado cuenta de que el vaso para llevar tiene que ser de un material concreto para no perder la esencia del saber.

• Yassir al ser la persona que diseña los locales se convierte en un cuello de botella de escalar el negocio porque parte del valor de Syra Coffee es ese cuidado en la experiencia.

• Se dan cuenta de que hay que invertir mucho en la formación de baristas para que cada café sea perfecto.

Mi método para mapear entrevistas

Mi método para mapear una entrevista como esta es:

1. Escuchar toda la entrevista sin anotar nada.

2. Volver escuchar toda la entrevista, ahora anotando usuarios, sus necesidades, y algunas capacidades para suplir estas necesidades.

3. Volver escuchar toda la entrevista, entendido como consideran cada capacidad y en que fase de evolución está.

4. Volver escuchar la entrevista, ahora entendiendo como quieren influenciar el mapa y qué inversiones están haciendo para ganar más mercado, o que fricciones han encontrado, que se convierten en inercia.

Recursos

• Wardley Map completo en Excalidraw.

• Learn Wardley Mapping.

• Wardley Mapping in Practice con un descuento del 20% usando el cupón 3QLY2W.

Muchas gracias por leer este post 😄.

Me encanta leer vuestras opiniones y feedback para ayudarme a mejorar. Podéis dejarme un mensaje en mi LinkedIn o dejarme un comentario usando los siguientes links:

• 😍 Me encanta

• 😐 Okey

• 😨 Mal