Liip Blog Kirby Fri, 14 Dec 2018 00:00:00 +0100 Latest articles from the Liip Blog en My Learnings from Product Management Festival 2018 (Day 2) Fri, 14 Dec 2018 00:00:00 +0100 In case you missed it, you can find my key takeaways from the first day in this article.

Pricing as a product feature

By Kapeesh Saraf, Senior Director of Product at Coursera

We don't often rework our pricing at Liip, except for our two products Rokka and Houston SaaS.
This talk caught my interest to see how Coursera handles it.

Kapeesh first shared an interesting "Demand vs. price" graph. He said it's your goal as a PM to know where your product price is located on this graph in order to understand your users' willingness to pay.
Obviously, demand fluctuates with price: the cheaper the more people you'll have, and the higher the less persons will signup.
In order to get your price right, there is no magic:

  • Understand your persona via A/B testing. For instance, at Zynga, Kapeesh noticed that not many people would buy his virtual toaster (what world we live in...). But the one who'd buy wouldn't care about the pricing. So he was better raising the price! He said he learnt this in hindsight, by doing A/B tests and post-analysis.
  • At Coursera, which is a more "mature" and established product (degree), his experience with user surveys proved to be the easiest to go with. Although it's always a matter of techiques' combination.
Pricing is also a feature
Pricing is also a feature

The second key takeway, "Pricing as a feature", is best explained via an example: Coursera used the loss aversion's human psychological trait to increase its retention. They told their students that they'd pay less if they completed their degree faster than standard. It was their way to make sure that people would choose Coursera over Netflix when they got home in the evening. And it worked! After three years using this model, all their metrics increased.

A final reminder that I commonly share with my Liip clients about their product scope: Keep It Stupid Simple (aka KISS). Kapeesh uses it as well for pricing. He shared that the more complex your price is, the more complex your product becomes. And as with scope creep, this makes you lose customers.

How to find the right UX strategy for my product

By Sibylle Peuker, Partner and UX architect at Zeix AG

The thing I learnt from this talk is the definition of a UX strategy. Such concept is a way to align UX and Business. Sibylle summarized it with an equation:

UX strategy = Thorough analysis (of the context) + Shared vision (of the product/project) + UX methods (get the right tools) + Avoid common pitfalls

As Sybille focused on the "Common pitfalls", it left me hungry as I expected the speech to answer my current question: which UX tools and strategy to use for which kind of product, concretely.
I'll have to keep evolving my own decision-tree graph (to be shared in a future article) as I didn't get any answers there.

The speech teaser was promising, but not aligned with the talk content
The speech teaser was promising, but not aligned with the talk content

Push Boundaries of Product Growth with Innovation Accounting

By Ilia Kuznetsov and Nick Mitushin from ABRT Venture Fund

I chose this talk to see concrete examples on how innovation accounting is used by a venture-fund company. If you wanna get an intro about the concept, I recommend you to read Eric Ries' "Lean Startup" book.

Nick sees innovation accounting as a way to index the growth of a product. It's pretty simple: make plans for a metric (e.g. how many new customers are expected) to be measured into a spreadsheet for the next two weeks. Do your product improvements. Then, two weeks afterwards, have a reality check. Did your metric increased? If yes, keep improving. If not, adapt your product strategy so it aligns with what growth you wanna generate.

The point that stuck with me is a mistake we, POs or PMs, all went through at some point. That is, to focus too much (if not only) on the product backlog or spend time scoring it.
Instead, we should put all our focus on discovering the growth goals. And only then, to deduct the product backlog from it. Not the other way around.

Pictures are worth a thousand words:

An example on how to analyze various growth scenarios
An example on how to analyze various growth scenarios
EggsTV business model scenarios analysis
EggsTV business model scenarios analysis
Tracking growth every two weeks, and adapting the product strategy accordingly
Tracking growth every two weeks, and adapting the product strategy accordingly

I also asked the two guys a question: "What cohort tool do you see mostly used by startups nowadays?"
They mentioned they used KISSMetrics in the past, but nowadays, Amplitude is THE thing recommended by their analytics team members.

A final important note: they always discussed about growth, not profit. While we often associate growth with money, growth can be about impact. Or about purpose as we practice it at Liip. When you start to see the talk and tools under this lens, you understand that they can be of help in many situation to avoid waste in what you craft.

Building accessible digital products for 100 millions users

By Saurabh Gupta, Program Manager at Microsoft

As with the speech by Minal from Google about the Next Billion Users, I feared to face a complacency talk. But Saurabh was clear from the start: he is driven by Microsoft's purpose "Empower every person", but he came here to talk about business, too.

He first quoted a consultancy firm: "Organizations who look at accessibility just as a compliance item miss out on business opportunities."

Backed by numbers, it indeed looks like a huge market opportunity:

  • 1 billion people globally are differently abled
  • 4.5% of the global population is color blind
  • 3.3% of the global population suffer from visual blindness
  • And 5% from earing loss

"Organizations who look at accessibility just as a compliance item miss out on business opportunities."

Other interesting facts on which industry put strong focus on accessibility:

  1. Education — for school and colleges
  2. Government — for citizen facing portal and tools
  3. Healthcare — for customer tools
  4. Enterprise — for equal employment opportunities

He continued explaining that accessibility is no rocket science. It just takes some time during the development process. There are plenty of certification's checklist on the web. We at Liip even open sourced a tool to check your accessibility compliance: A11ym.
But the basis of all certifications remain the same: any electronic and info tech must be accessible to people with disabilities. Punkt.

The main options to enable accessibility are:

  • Use icons on top of colors only
  • High contrast & dark them
  • Screen reader ready
  • Text size and display option
  • Touch target size
  • Closed captioning

As with UX or KPI setting in a digital project, accessibility should be a design parameter. Else, if done only at the end, it ends up being too costly.

All in all I agreed with what Saurabh spoke about during his speech. Moreover with his closing sentence: Accessible design is inclusive design.

To summarize the talk:

  1. Think accessibility at the design stage
  2. Designs are final only if they're adhering to accessibility standards
  3. Define an accessibility section for your PM specifications
  4. Call the feature complete only with accessibility supported
  5. Perform accessibility testing with at least one blind user

And if it helps you, think about accessibility in business terms. It's definitely a market advantage over your competitors.

Simple icon-on-top-of-color example on how to improve the life for color-blind people
Simple icon-on-top-of-color example on how to improve the life for color-blind people

Becoming a problem solver

By Michael Perry, Director of Product and Marketing Technology at Shopify

We got to be careful about the product culture we've built. I often call this "solutionism". We must focus on problems first.

That's how Michael started the final keynote. 100% aligned from the beginning to the end!

I could relate to his chart about the addictive product creation loop (and I'm sure you do if you're an entrepreneur with 10k ideas per second):

  • You have an idea
  • You conceptualize the product, even in your head (the fun part)
  • You launch the product
  • You get your heroin dose, aka instant gratification, like buying the domain name, or kickstarting the project locally on your laptop
  • You get your early learnings while trying to find the product-market fit
  • You iterate, measure & enter hope phase
  • "Why aren't people using this?" I know! Let's build new features
  • Your mind starts to wander, you lose product interest
  • You sunset the product
  • You do a team/personal retrospective
  • And then, you start the loop over again!

To avoid this addiction, you should ask yourself this simple question:

What problem am I solving?

And to see if you're on the right track, just check if customers pay you for your service. If not, then you're not fixing one of their problem.

I loved the analogy given by Michael when he was trying to build his "Kit" product (that was then acquired by Shopify). He said: "Small business owners would rather do their taxes than marketing on Facebook."
It took him several years to answer why small business were failing at doing marketing right:

  • It seems it's because they try to do it all by themselves
  • So why aren't they hiring new people?
  • Because they have no time, no money, no trust, no way for doing so.

So Michael built the first VA employee. Via text SMS to Kit.
Once he focused on solving the problem so much, then he even forgot about the "idea" thingy.

One of his saying still resonate with me: "Product visionaries are a by-product of being problem solvers."

The key takeaways from his great story:

  1. Don't chase (technology) trends
  2. Don't chase vanity gratification in order to stay motivated
  3. Don't fake product success with vanity KPIs (don't care about # of downloads)
  4. Don't quit over failed product ideas, because you'd focus on the problem
  5. Obsess over the problem, not the solution. Do not care about the solution
The addictive cycle of product managers. Break it by focusing solely on the problem.
The addictive cycle of product managers. Break it by focusing solely on the problem.


These were my notes from the second day at the Product Management Festival 2018 edition.

My key learnings:

  1. Pricing is a feature of your product in itself. Tweaking it alone can make your client use your product even more (example of Coursera lowering its price if you finish your degree in advance)
  2. Innovation accounting is a simple spreasheet to track whether your fancy JIRA stories get an impact on key KPIs such as number of new clients or so
  3. Amplitude is the tool recommended for product analytics (i.e. cohort analysis) these days
  4. Accessibility is inclusive design. But business-wise, accessibility is also 1/7 of market share of the entire planet. I'd say that 5% of a product budget is necessary if you apply accessibility upfront. 10-20% if afterwards. For sure, accessibility is no more about compliance
  5. A good product manager focuses on problems. Relentlessly. Moreover, he doesn't care about the solution, except when it starts to fix a real problem

This conference is great. I can't help but to recommend it if you're a Product Manager or Product Owner. I'll definitely attend next year.

Digitalisierung erleben: EKZ Prototyping Workshop Tue, 11 Dec 2018 00:00:00 +0100 Der Workshop

Vor zwei Wochen konnten wir unser erstes 3.5 stündiges Prototyp Training mit Mitarbeitern der EKZ durchführen. Die von uns im Workshop gestellte fiktive Aufgabe war, eine App zu entwickeln, die einen Nutzer bei der Urlaubsplanung, während oder nach der Reise unterstützt. Die Aufgabe war sehr offen gestellt. Die primäre Persona haben wir grob vorgegeben: in Form eines jungen Paares, eines Individualreisenden, einer Familie oder eines Teilnehmers einer Gruppe.

Im ersten Schritt baten wir die vier Gruppen, sich für eine Persona und somit ein vorgegebenes Setting zu entscheiden und die Persona dann auszuarbeiten: Was für eine Art der Reise plant die Persona? Wer ist ihre Begleitung? Welche Bedürfnisse hat sie im Zusammenhang mit der Planung oder Durchführung der Reise? Auf welche Schwierigkeiten stösst sie dabei?

Danach hat jede Gruppe eine User Journey für ihre Persona erarbeitet. Es wurde festgehalten, welche Tätigkeiten die Persona in welcher Reihenfolge tun möchte. Aufgrund der Persona und der skizzierten User Journey, haben die Teilnehmer entschieden, welche Bedürfnisse die App bedienen soll und welche Funktionalitäten dafür geeignet sind.

Schlussendlich kamen wir zum “handwerklichen” Teil des Workshops und haben die App in Form von User Flows und Screens gezeichnet: in Form eines einfachen Papierprototypen. Diesen haben die Teams sich gegenseitig vorgestellt und Feedback gegeben.

Wir sind begeistert und finden, es sind tolle Ideen entstanden: eine App, die einen Reisenden mit Hund während einer Wanderung auf dem Jakobsweg unterstützt. Neben spezifischen Informationen rund um den Hund bietet sie Orientierung und Hilfe – aber sie gibt auch gleichzeitig Hinweise, wie es möglich ist, für sich zu sein und den Weg möglichst alleine zu machen. Oder eine App, die den Mitarbeitern der EKZ ermöglicht, ein Team für einen Iron Man aufzustellen. Die App koordiniert die Teilnehmer und ihr Training. Aber auch nach dem Event hat die App etwas zu bieten: eine Bildergalerie und eine Möglichkeit sich erneut anzumelden, denn nach dem Event ist vor dem Event...

Unsere Learnings

Bei der Planung waren wir uns nicht 100% sicher, ob man den User Centered Design Prozess so komprimiert durchlaufen kann. Und auch der Sprung von einer Aktivität (User Journey) zu einer Funktionalität (Papierskizze eines Screens der App), schien uns ziemlich gross. Aber es hat ganz hervorragend funktioniert. Der Grund ist, dass alle Teilnehmer bereit waren, sich auf das Experiment des nutzerzentrierten Denkens und Skizzierens von Hand einzulassen.

Es war schön zu beobachten, dass auch in Teams, die sich nicht täglich mit der Entwicklung digitaler Produkte beschäftigen, in kurzer Zeit Ideen entstehen, die in einfachen Skizzen zum Leben erweckt werden.

Ein Wunsch, den wir vorher nicht so realisiert haben, aber für unseren nächsten Workshop berücksichtigen werden, ist das Interesse an der Technologie: vielleicht werden wir in unserem nächsten Workshop eine Landschaft an gängigen Tools zeigen – neben Stift und Papier – wie man einerseits Prototypen aber auch Apps erstellen kann. Darüber werden wir nachdenken. Es war auch für uns ein sehr lehrreicher und spannender Abend! Denn wie David L. Rogers sagt, „Constant learning and the rapid iteration of products before and after their launch date, are becoming the norm.“ (vgl. David L Rogers, The Transformation Playbook). Ein herzliches Dankeschön an Herrn Hauser, der uns die Möglichkeit gegeben hat den Workshop bei der EKZ durchzuführen und zu lernen!

Entity Explorer, your trusty helper 🐕 Wed, 28 Nov 2018 00:00:00 +0100 When you are building complex Drupal websites you rely on entities, and they are often entities within entities, linked to entities, and so on.

When you need to debug data deep down in the persistence layer, be it in a moderation state, language revision or somewhere else because Drupal gives you an inconsistent response, where do you begin?

The debugger?

A great start is setting a breakpoint instead of just trying to observe the data structure as it passes through your call with kint(), print_r() or the like.

Xdebug is certainly a very good route to discover the state and properties of a specific entity. However, it is often insufficient to debug complex entity relationships in an efficient manner: Child entities might only be visible as their target ID or dynamic properties are empty because they have not been built yet.

The database?

Another place to look is the database, and that’s fine. It is of course the final say on the persistence layer but has significant disadvantages: writing joins by hand to discover the linkages of fields and tables is at best cumbersome and downright annoying when you are jumping from entity to entity. Also, reusing and managing such query snippets is not easy.

Entity API?

So your next step would likely be to write a custom script and make use of entityTypeManager. It can answer most complex queries and if you have done a little bit of Drupal 8 development you’ll likely already have come across it. Just select the desired storage, fetch a query, add your conditions and you can access the relevant revisions, their fields, and properties with ease. In some cases you might need to include some help from EntityFieldManager.

Drupal 7 hint: If you are stuck on a site you can’t migrate just yet, you can still make your life easier by using entity_metadata_wrapper() and EntityFieldQuery. You don’t have to live with stdClass objects and raw database queries.

However, you’re still writing a lot of common queries repeatedly by hand, when you just want something more efficient than digging through revisions in the UI for a particular problem.

Entity Explorer

Entity Explorer is a simple Drupal Console command which uses just a handful of entityTypeManager commands to build you an efficient output of an entity across languages and revisions including child elements, if needed:
$ drupal entity_explorer node 16287 47850 # Arguments: type, id, revision (optional)

The first example shows the translation revision of a node with the IDs of embedded entities. Use --all-fields to recursively show their details:

Check it out:

composer require drupal/entity_explorer:~1.0

My Learnings from Product Management Festival 2018 (Day 1) Tue, 27 Nov 2018 00:00:00 +0100 This know-how helps me a lot to build the right product for each of our customers and their end users, and not only to build it right by using Scrum.

I went to the Product Management Festival 2018 edition two weeks ago in order to learn about current the best practices in the field.

You find below the notes and learnings I took away.

Power of transparency

By Christian Sutherland-Wong, COO at Glassdoor

There are two things that stuck with me after the talk:

  1. Glassdoor wishes that every company would be more transparent about salaries. But internally, they don't openly share them. We made the move to full salary transparency here at Liip. I can't help to recommend any company to do so, as it only brings more fairness. On the short term, there are painful discussions to have. But it pays off on the long term, as people with salary issues get to understand why, and are then able to improve. Hopefully Glassdoor makes this move soon too.

  2. Christian also talked about monetization. As an entrepreneur myself, that's a topic that I love to discuss as it's so challenging to find the best ways to make money in a way that is win-win for the the entrepreneur and the client/user. As the saying goes: "Revenue is like oxygen for a startup. We don't live for it, but we need it to live".
    I disagree with him about one point: he explained that monetizing vanity was one key way to make money from their product at Glassdoor.
    My (potentially hasty) conclusion from this statement is that it sounds like the most economically viable solution. I'm challenging it because, as a CEO or founder, I would focus on finding better value for money strategies. I don't think exploiting such human nature trait foster better behaviors. I prefer having less paying customers, but that get real value from it. And there is for sure good value in Glassdoor who helps employees have the same information access as companies get when they interview you.

If you read these lines Christian, feel free to share your opinion in the comment section below.

"Power of transparency" speech by Glassdoor COO
"Power of transparency" speech by Glassdoor COO

Startup versus Enterprise Product Management

By Tom Leung, Director of PM at Youtube

This talk resonated a lot with me, as I feel that Liip and our self-organization model provides the best of both world: having your own startup, within the comfort of a company with 180 employees.

Here is what I learnt (or rehearsed) that is applicable to any products/projects you could have, independently of your company's size:

  • The only thing that matters is product-market fit and repeatable growth to sustain on the long run. And not your big media coverage, nor your invitation to talk at this big conference. These latter are only vanity metrics, that should come as results and not objectives in their own.
  • Would you use your product if you weren't in this company? If not, then you're probably building the wrong thing. Or at least it will be harder for you to stay motivated month after month.

From Tom's experience if you go for big corporate career:

  • You'll have to balance the "Just ship it and see what happens" with global scale impact (like you can't have YouTube go down every week)
  • You'll need to accept and cope with some (long) discussions to convince and rally people to follow you (aka. politics). Else you're better to stay at your startup.
  • You'll have to motivate teams and earn credibility — you don't have any CEO nor founder title to help you there
  • In certain "modern" corps like Google or Spotify, you can be lucky to have small cross-functional teams with a lot of flexibility
  • Startup veterans are like wild horses, and it's very hard for true entrepreneurs to go to big corporation. Often, after acquisitions, you see founders leaving. Not because they don't fit. Just because they need to move on and craft their next thing.

Regarding his startup's career:

  • Startup move fast. Every day. And that's a drug hard to give up once you sensed it.
  • When you're in a startup that grows, you quickly have to take care about management, marketing, and all sort of boring stuff. Make sure to keep the biggest chunk of your time dedicated to your product. Because that's what makes your company first. Easier said than done :)

Tom closed the talk with 3 skills a PM need to have:

  • Great judgment: being able to take imperfect infos and making a call. And being often right with such calls
  • Delivering results: "This product growth happened because it was this PM in the team"
  • Customer insights: go talk to customers. Go in the street. Go out of the building. Do whatever it takes but talk to real customers

This led me to this discussion with Tom after his session:

How a Product Manager can hone his judgment skills
How a Product Manager can hone his judgment skills

Viral loop

By John Koenig, Senior Product Manager Growth at Typeform

I mostly rehearsed knowledge, but it was still interesting to see how they apply it at Typeform.

One of the trick to ensure self-fueled growth of a product is to make use of viral loop.
A viral loop relies on the viral coefficient. Put simply it's the number of new users that an existing user generates. A 0.3 coef means that for each 10 users, you will get 3 new users. If you get above 1.0, then you get exponential growth.

John explained the viral loop model he uses at Typeform:

  1. Signup: creating a typeform account requires only 3 fields for lowest friction possible.
  2. Motivation: here comes their value proposition, which is sharing a Typeform form. To support this, they provide plenty of options so that you, as a customer, find a way to share your form and don't leave the platform there.
  3. Share: the nice fact is that sharing can be part of your product, like Typeform which goal is to be shared to collect responses. That surely help to develop your own viral coefficient.
  4. Impression: finally, when using the product, there are some tricks to leave your name around. Like the Intercom tool design that, even when customized is recognizable. Or Kickstarter, which you may use in 3-5 years when you suddenly get this idea of a new product to be backed up. At Typeform, their easily identifiable's user interaction and bottom logo play this role.

Once this loop is completed by one user, the new acquired customers fuel the viral loop themselves.

GIST planning

By Itamar Gilad, Product, Strategy and Growth Consultant, Ex-Google PM

GIST stands for Goals, Ideas, Steps, and Tasks.
It's a product framework imagined by Itamar while he was PM at Google. It mixes Lean Startup and Agile concept to align people from top management to delivery teams.

It aims to avoid the pattern consisting of: the strategy definition, then the roadmap building, then split into project plans, then the (Agile) execution done waterfallishly.

Below are the key elements of GIST planning:
You define goals using the OKR system for the next quarter. It's easy to adapt on the go, and is easily defined between stakeholders. And it's transferable/visible to anyone in the organization.

Below the "Goal" timeline, you then have to fill your tank with ideas to accomplish this objective. The more you fill the tank the better, knowing that only 1/3 of ideas are good at supporting objectives. Afterwards, you evaluate your ideas against a prioritization-by-evidence mechanism, like the ICE one (standing for Impact, Confidence, and Ease) popularized by Sean Ellis.

Once you found your next idea to validate, you go into a 10 weeks block of experiments as with the Lean Startup methodology.

Each experiment above can be seen as a Scrum sprint or can be detailed using Kanban. You can use whatever tool you're used to working with for this.

As you can see, compared to waterfall then Agile iterations, you get the whole system to iterate as a whole.
That's somehow how we operate at Liip, but a lot less formally. I will apply it on a small scale project to see how it works, and experiment with the pros and cons.

For a mental model's addict as I am, it was quite of an interesting session.

If you wanna learn more about GIST, I recommend you this reading.

GIST planning overview
GIST planning overview

The anatomy of influence power

By Stephanie Judd and Kara Davidson (both founders of Wolf and Heron)

The definition of influence is to "change how people think and act".
After this first sentence from Stephanie, my first reaction was "No thanks, I don't wanna become one of these manipulative people."
My second reaction was: "Well, I influence my kids every day for educational purpose. I also influence my clients to show them how Lean Startup, Agile, and self-organization principles are great. So it may not be that bad to learn more about this topic."

Stephanie and Kara then explained that infuence is made of two things: power (given to you, and situation agnostic), and pathway (which is situation specific, depending on which path you choose). They focused the rest of their talk on the power part, as it's situation-agnostic, so applicable to the biggest number of people in the room.

Power has 9 main sources:

  1. Expertise: what you know and can do
  2. Title: formal role and authority, as proxy of our influence
  3. Likeability: the first impression that other people have about you (posture, physical looking, sense of humor)
  4. Familiarity: your history and closeness with a specific person, gained through shared experiences
  5. Network: some tips are to focus on diversity, doing small favors to pay forward without expecting rewards
  6. Communication: be precise, be focused on the conversation (no smartphone on the table when talking to people)
  7. Reputation: what people say when you're not here. The best way to score point is honesty. With everybody.
  8. Resources: aggregate, organize, and redistribute it in your own way to add value to it (what I try to do with this blogpost, commenting and challenging ideas that I learnt)
  9. Grit: the desire and courage to act. It's an accelerant for all points above. Everyone has it. It's a muscle. The more you train it, the more you get good at it. Make sure you know your why first, then act on it. Relentlessly.

That's for another mental model of what power sources I can activate to better influence people.
As with any power sources, it's better and stronger when it's balanced. By the way, their company Wolf and Heron provides a "Personal Influence Diagnostic" on their website if you're interested to develop this part of yourself.

Ah, and don't forget, if you change how people think and act for bad reasons (including selfish ones): that's manipulation. You don't wanna do that.

Wolf and Heron's Personal Influence Diagnostic
Wolf and Heron's Personal Influence Diagnostic

Building for the next billion users

By Minal Mehta (Head of Product at YouTube, Emerging Markets)

The famous NBU as they now call it. The Next Billion Users. To be frank, I feared to only hear the message "We at Google will change every single part of the world". I was surprised by Minal's honesty when during the Q/A someone asked why big companies didn't ally to have a bigger impact. Her answer: "NBU is a market, and we're doing business there, not non-profit."

Moreover, what she shared was down-to-earth and aligned with my beliefs.
Before listing my takeaways, I will put below my notes about this big market that is India which is important to know for global corporates as this market rises strongly.

  • People in India are way more social than we are. So much that they share their own phones.
  • Data usage becomes more and more cheap, connecting a lot more people to the Internet.
  • Feature phones (think Nokia 3310 but with a decent web browser) are kings due to their price. That's one of the reason behind the launch of Android Go. Thus you need to think interfaces and interactions differently if you target this market.
  • As Mina confirmed with her research on the ground, Indian people are consuming content for the same matters as the rest of the world: messaging, getting info, and entertainment. And they expect to be treated as well regarding UX as Western mobile users.

Again, if you build a local product for Swiss people, that may not be interesting. On the other hand, if your digital product is useful worldwide, then you better start to plan your future holidays where one additional billion users will get access more and more to your tools. Nothing breaking new, but worth the reminder.

What resonated the most with me in this talk are the five lessons that Mina learnt on how to build great teams, and stay connected with them. This to overcome the project problems the best way possible.

Lesson #1: find people who believe in the product you're building. Additionaly, make sure they're comfortable with ambiguity, that they can manage their energy, and that they want to draft with their teammates

Lesson #2: rally your team around the user and the specific needs you're solving. This specific point is critical to me, and it proved to be a game changer every time I applied it, by asking our client to give us a tour of his company and activities, physically, before starting the project and with the entire Liip team.

Lesson #3: create a culture of psychological safety. Leave room for failure, without stress, and most importantly for being one-self. I could write hours about the impact of such culture as it makes us thrive both socially and economically at Liip.

Lesson #4: leave the building to connect with your team. We like to do project retrospectives at a coffee (which happens to be a bar too:)) near our Lausanne office. The place and its atmosphere impacts a lot the outcomes, positively. I recommend you to try it out.

Lesson #5: always celebrate your wins. Always. One simple way of how I organize it is by putting myself a calendar reminder 1 month before the planned launch to schedule a "Celebration lunch". That helps everyone to see the golive positively, not stressful. Obviously, you need to celebrate smaller wins along the way too.

Next Billion Users market overview by Minal Mehta
Next Billion Users market overview by Minal Mehta


That's it for my notes from day 1 at the Product Management Festival 2018.

To summarize, here are my key learnings:

  1. Monetization is a tough topic, even more if you wanna do it with an "added value" mindset.
  2. I'm grateful to work in one of the few Swiss companies that is self-organized, and offers the startup spirit (i.e. small teams, fast decision-making, almost no politics, and a safe-to-fail environment), all while having all advantages of a 180-employees company. The best of both world.
  3. The viral loop and coefficient are concepts that should be grasped by any Product Manager/Owner as they can tremendously help your product to be spread to your audience, and ensure a sustainable growth.
  4. GIST planning is a useful framework to iterate at all levels from vision, down to the daily operations, vs. only at the daily operational level.
  5. You can influence your own influence power. If done for the right purpose, it can only help you to have more and better impact on the world. There are 9 areas to introspect and make evolve. Wolf and Heron provides a guide on which ones to focus first for you.
  6. Building a cohesive team is important for when you face roadblockers while crafting a product. It will help to overcome them if you are feeling like one entity, and not separate individuals. There are down-to-earth ways to foster such teams. It requires energy upfront, but the investment is worth it on the long term.

I see you very soon for the summary of day 2!

I also take the opportunity of this first post to thank Liip to be so smart to let each of us choose our own further education path. Takeaways were important for me on both the personal and professional levels.

Were you at the PMF 2018? Do you agree with my comments? Any other insights I missed?

Secrets behind the launch of the new Compex Coach mobile app Fri, 16 Nov 2018 00:00:00 +0100 Last June, we started to create a second mobile application with Compex (brand part of the DJO Global group) who is leader in the muscle stimulation sport world, for both performance and recovery matters. The mobile app goal was to be the companion of Compex device users, in order to help them reach their objectives (performance, recovery, pain management, etc.) — feature that aren’t present on the physical hardware itself.

Helping hardware devices to last longer

At Liip, we love products that are made to last, and not to make users consume more. Obviously one has to run his business, but Compex vision with this mobile app really seduced us. For them, this app is a way to make the devices of their users last longer. Indeed, by putting the fast-moving part — that is the software — inside your smartphone instead of the device itself, they ensure an experience that is always evolving,while increasing the longevity of their device (that is well known for its strong quality in the sport market).
A lot of users are still very happy with their 2014 Compex equipment. And Compex supports them in doing so. We love that.

Compex Coach app listing the products of Compex

Choice of your device within the Compex range

Adding value to users

When Matteo Morbatti, International Product Director at DJO/Compex, brought us the project idea of replacing Compex paper user manuals by a mobile app, we were a bit skeptical. We didn’t want to just publish an app for the sake of having one.
He then continued his brief explaining that this was a real need of his customers, but that he wanted to make something more than just putting a PDF into a mobile app. He wanted to make the “What should I do now that I’ve bought my device” problem easier to solve via an app where we would guide the user from the day he unboxes his product.
That’s how we ended up to structure the digital tool in a way that it asks you “What is your objective?”, and then make use of all the user manual key infos at the point where the user most need it. That is, after setting his objective for the body zone he wants to reinforce or develop. “The right action at the right time”, as we like to describe in our mobile realm.
This way, people get real value with this accompaniment, versus the non-engaging paper version they had beforehand.

Features of the Compex Coach app

The right action and information, at the right time

"Compex had identified a need for these users and decided to respond by creating an app: Compex Coach. For this project, Compex turned to Liip and made no mistake. Having personally taken an active part in the development of this project, I can assure you that the collaboration throughout the project has been fruitful and motivating. Liip's project team is very professional and delivered this app on time and on budget." Matteo Morbatti, International Product Director at DJO Global/Compex

Marketing, done right

Compex also needs to do its business, and to work on converting clients into regular ones. One of the business objectives was to retrieve user’s email address in order to send them valuable infos on how to best use their product.
Instead of adding a mandatory email field to use the app, Compex went a step further and played it the win-win way: they offer in clear words two incentives that are a guarantee extension of 1 year, and a discount on consumables that you need as a regular Compex user.
Most importantly for us at Liip, these two incentives are options. If you refuse, you can still continue to use the app freely. And if you accept, you get something in exchange. We let the choice to the user in the end.

Reviews from the Play Store with a 4.5 rating

Google Play Store rating when you add real value to people lives

Next steps

One of our core philosophy at Liip is to “start small and iterate” in everything we do. Matteo and his Compex team have the same mindset. This allowed us to launch this new product in less than 3 months. Yes we could have built the cloud connection (to store your objectives online), or the always-up-to-date user manual instructions. But instead, we built the minimum viable solution and launched it. This allows us to learn as quickly as possible from the end users and to integrate their feedbacks with the next release when we will craft the cloud part of the solution.
A proof that this is one of the best way to build product is that Compex clients ratings are speaking by themselves (4.2/5 on the Apple AppStore, and 4.5/5 on the Google Play Store), and this “only” with a minimum viable solution. We can’t wait to delight them even more with all those cool new features!

PSR-18: The PHP standard for HTTP clients Fri, 16 Nov 2018 00:00:00 +0100 First, PSR-7 "HTTP message interfaces" defined how HTTP requests and responses are represented. For server applications that need to handle incoming requests and send a response, this was generally enough. The application bootstrap creates the request instance with a PSR-7 implementation and passes it into the application, which in turn can return any instance of a PSR-7 response. Middleware and other libraries can be reused as long as they rely on the PSR-7 interfaces.

However, sometimes an application needs to send a request to another server. Be that a backend that uses HTTP to communicate like ElasticSearch, or some third party service like Twitter, Instagram or weather. Public third party services often provide common client libraries. Since PSR-17 "HTTP Factories", this code does not need to bind itself to a specific implementation of PSR-7 but can use the factory to create requests.

Even with the request factory, libraries still had to depend on a concrete HTTP client implementation like Guzzle to actually send the request. (They can also do things themselves very low-level with curl calls, but this basically means implementing an own HTTP client.) Using a specific implementation of an HTTP client is not ideal. It becomes a problem when your application uses a client as well, or you start combining more than one client and they use different clients - or even more when needing different major versions of the same client. For example, Guzzle had to change its namespace from Guzzle to GuzzleHttp when switching from version 3 to 4 to allow both versions to be installed in parallel.

Libraries should not care about the implementation of the HTTP client, as long as they are able to send requests and receive responses. A group of people around Márk Sági-Kazár started defining an interface for the HTTP client, branded HTTPlug. Various libraries like Mailgun, Geocoder or Payum adopted their HTTP request handling to HTTPlug. Tobias Nyholm, Mark and myself proposed the HTTPlug interface to the PHP-FIG and it has been adopted as PSR-18 "HTTP Client" in October 2018. The interfaces are compatible from a consumer perspective. HTTPlug 2 implements PSR-18, while staying compatible to HTTPlug 1 for consumers. Consumers can upgrade from HTTPlug 1 to 2 seamlessly and then start transforming their code to the PSR interfaces. Eventually, HTTPlug should become obsolete and be replaced by the PSR-18 interfaces and HTTP clients directly implementing those interfaces.

PSR-18 defines a very small interface for sending an HTTP request and receiving the response. It also defines how the HTTP client implementation has to behave in regard to error handling and exceptions, redirections and similar things, so that consumers can rely on a reproducable behaviour. Bootstrapping the client with the necessary set up parameters is done in the application, and then inject the client to the consumer:

use Psr\Http\Client\ClientInterface;
use Psr\Http\Client\ClientExceptionInterface;
use Psr\Http\Message\RequestFactoryInterface;

class WebConsumer
     * @var ClientInterface
    private $httpClient;

     * @var RequestFactoryInterface
    private $httpRequestFactory;

    public function __construct(
        ClientInterface $httpClient,
        RequestFactoryInterface $httpRequestFactory
    ) {
        $this->httpClient = $httpClient;
        $this->httpRequestFactory = $httpRequestFactory;

    public function fetchInfo()
        $request = $this->httpRequestFactory->createRequest('GET', '');
        try {
            $response = $this->httpClient->sendRequest($request);
        } catch (ClientExceptionInterface $e) {
            throw new DomainException($e);


The dependencies of this class in the "use" statements are only the PSR interfaces, no need for specific implementations anymore.
Already, there is a release of php-http/guzzle-adapter that makes Guzzle available as PSR-18 client.


PSR-18 does not cover asynchronous requests. Sending requests asynchronous allows to send several HTTP requests in parallel or to continue with other work, then wait for the result. This can be more efficient and helps to reduce response times. Asynchronous requests return a "promise" that can be checked if the response has been received or waited on, to block until the response has arrived. The main reason PSR-18 does not cover asynchronous requests is that there is no PSR for promises. It would be wrong for a HTTP PSR to define the much broader concept of promises.

If you want to send asynchronous requests, you can use the HTTPlug Promise component together with the HTTPlug HttpAsyncClient. The guzzle adapter mentioned above also provides this interface. When a PSR for promises has been ratified, we hope to do an additional PSR for asynchronous HTTP requests.

Defining a company’s voice in three steps Tue, 13 Nov 2018 00:00:00 +0100 For this project, which focused on updating texts, we aimed to:

  • Ensure the text's quality and coherence between the different sections of the website
  • Facilitate the work of the editorial team for the long term

This article explains our methods for the project. We worked in stages:

  1. Defining OCN’s identity
  2. Verbalising OCN’s identity in a form that was easy to understand and share
  3. Defining the bases of OCN’s voice

Defining a company’s voice helps an editorial team to understand how to convey their identity in written form.

1. Defining the company’s identity

What does that mean?

A company’s identity forms the basis of its voice. If a company’s identity is clearly defined, its voice is also easy to define.
A company’s identity is its purpose: why you do what you do. Simon Sinek’s video,Start with Why , clearly explains the importance of this question.

Your company has a purpose beyond the money you make, beyond the things you do. The better you put it into words, the better you can see it – we can only see what we have put into words. Once you have put it into words, others can see it and focus all of their efforts into making it happen. It makes work unfulfilling when we don’t know what we are working towards.
Simon Sinek, extract from the presentation Start with Why

The example of OCN

Legal foundations defining the functions and services provided by OCN. A charter defines the concept of public service.

Based on OCN’s internal charter, we formulated various questions such as:

  • Why does OCN admit drivers and vehicles to road traffic?
  • Why does OCN admit drivers and boats to navigation traffic?
  • Why does OCN organise prevention activities and courses?
  • Why does OCN enforce administrative measures (warnings and driving licence withdrawals)?
  • Why does OCN collect cantonal and federal taxes (levies on vehicles and boats, charges on heavy goods vehicle traffic)?
  • Are the activities grouped into categories?

During a workshop, we talked to members of the OCN project team to bring internal tacit knowledge to the fore.

In OCN’s case, we were also inspired by the websites of companies in the road safety sector.
The OCN team shared links and images of textual content that they considered to be ‘engaging’ or, alternatively, ‘overly complex’. The team explained how and why they thought this text content was ‘engaging’ or ‘overly complex’.

How can you do it?

Are your company’s activities clearly defined, yet there are no documents defining your identity or values? Ask yourself what the purpose of your company is: Why do we do what we do? Who are we? You will find some answers by reading internal documents, talking to your colleagues, and comparing your company to your competitors.

Read existing documents
You will find answers to the question Why do we exist? in documents entitled ‘corporate identity’ or ‘brand manifesto’, or in the charter of values. If such documents do not exist, talk to your colleagues.

Talk to your colleagues
Talk to your colleagues, such as the company founders and people who are in contact with your customer base. Capturing existing knowledge is vital.
You can help your colleagues to verbalise their ideas by asking questions.

For example, you could ask:

  • In your view, what is our company’s most important activity?
  • Why do we do this activity?
  • Why is this activity important?
  • If we stopped this activity, what would it change for our customers?
  • Are we leaders or followers in our field?

Analyse your competitors
Analysing your competitors will allow you to identify your position in relation to them. For example, you could perform a SWOT analysis to define your strengths and weaknesses in comparison with your competitors.

During your analysis, you can also compile examples of communications that you value highly or that you wish to avoid. This will help you definining your position.

2) Verbalise your identity in the form of a vision and a mission

What does that mean?

In point 1, we compiled the key points defining your company’s identity. Now, the aim is to summarise these key points using vision and mission concepts. That is an easy way of sharing the central elements of the identity.
Your vision explains to your customers who you are, and your mission explains why you do what you do.

The example of OCN

We used Simon Sinek’s circle. During a workshop, we asked members of the team about OCN’s activities (Sinek’s How) and the aim of these activities (Sinek’s Why).
After drafting a vision and a mission, we asked for feedback from the project team to ensure that we had correctly expressed OCN’s identity.

How can you do it?

Use your research from point 1 to draft your company’s vision and mission. Be precise and concise. Avoid adjectives that are subject to interpretation such as good, nice, lovely.
Your vision conveys who you are in your sector or in relation to your customers: We are a leader in..., we are partners, we are consultants, etc.

Your mission explains what you do, above and beyond profit: We provide equality in..., we promote innovation in..., etc.

Request feedback from your colleagues
Test what you have drafted by asking your colleagues’ opinions. Ask questions like:

  • Does this statement represent our company?
  • If not, which word would you replace to represent our company?
  • Does this statement represent why we do what we do?
  • If not, which word would you replace to correctly represent why we do what we do?

If you have to explain or justify your choice of words, your draft is probably not clear. The aim is for the team to agree that ‘yes, that statement represents who we are, yes, that statement represents what we do’.

3) Define the basic principles of your voice

What does that mean?

Building on your vision and your mission, use adjectives to define how your company expresses itself. These basic principles will guide your editorial process.

The example of OCN

In OCN’s case, we selected three series of three adjectives that define OCN’s voice. Here are two examples:

We use everyday language to be understood by all. We explain the terms and concepts that we use. We support our customers by drafting texts that enable cross-reading.

Our language is suitable in all circumstances, no matter who we are talking to. We avoid judgemental adjectives and vocabulary loaded with alternative meanings.

How can you do it?

Choose three to seven adjectives, depending on the complexity of your voice. We recommend pairing each adjective with a brief explanation. Avoid adjectives that are subject to interpretation such as good, nice, lovely.

You could help your colleagues by suggesting adjectives, for example using post-it notes or a card game. You could ask them:

  • Are we meticulous?
  • Are we trendsetting?
  • Are we wacky?

Request feedback from your colleagues
Test what you drafted by asking your colleagues’ opinions. Ask questions like:

  • Does this adjective define how our company, or our digital product, speaks to our customers?
  • If not, what is the right adjective?

Look for collaboration and suitable solutions.

Key points to remember

  • Your company’s voice is based on your company’s identity
  • Draw inspiration from your charter, values, and colleagues’ knowledge to define your company’s identity
  • Examine how your company is positioned compared with your competitors
  • Aim for collective agreement by asking for feedback from your colleagues
  • Define a series of adjectives that are the principles for your voice

Share the love <3

Thank you to the OCN team, especially Fanny and the editorial team for being motivated and welcoming!
Thank you to Yves for his involvement and enthusiasm throughout the project!
Thank you to Darja, Jérémie and Tom for their valuable advice and feedback!
Thank you to Sara, a recent arrival at Liip who is already providing motivation!

Our suggested reading to learn more about this topic

Erika Heald (Content Marketing Institute): 5 Easy Steps to Define and Use Your Brand Voice
Kinneret Yifrah article posted on Medium, 6 reasons to design a voice and tone for your digital product
And of course, here is a link from my colleague Caroline on how to ensure that your voice is strong and heard.

TEDx - make a wish Wed, 31 Oct 2018 00:00:00 +0100 Destination Tomorrow

We have been partner of various TEDx programmes for many years. This year, we sponsored TEDx events in Bern, Fribourg and are about to go to Geneva. TEDx is a forum for ‘ideas worth spreading’. It consists of self-organised events in various cities. As part of last year’s ‘Destination Tomorrow’ TEDx event at HSG in St. Gallen, we wanted to show how innovation and digitalisation could be combined.
The wish tree
We worked on visions of the future with around 400 participants across seven lecture halls at HSG. The focal point of the event was our wish tree. A wish tree is a living tree, either indoors or outdoors, onto which wishes are hung. The wishes symbolically grow towards the sky with the tree, and so are incorporated into the greater whole. Participants at the event could write down one or more wishes and attach them to our wish tree. There was the possibility to send us the wishes online too: We looked through all the wishes, and were astonished by what we found!

Young people wished for world peace and sustainability – and a relationship.

The majority of the wishes were about the well-being of humans and nature. ‘World peace’ and ‘green technologies for all’ made an appearance. Most young people and participants wished for a more peaceful world and for sustainability. We thought this was remarkable! Of course, there were also personal wishes such as successfully completing a university degree, which is of course perfectly OK. One wish particularly caught our eye: ‘I wish for a girlfriend’. He hung his number on the wish tree. Hats off for audacity! Although we could not couple him up, we gave him a cool present for his pluckiness.

Outlook for TEDx events

There are will be more TEDx events for us to come in 2019. The wishes collected at the TEDx in St. Gallen touched us, so we are making another wish tree in Geneva. This will follow the same concept but be in a different format. Do French-speaking Swiss people have different wishes? We will find out on 7 November. Les Jours qui viennent – TEDx Geneva. We are once again organising a Liip bar. Meet us there! Or send us your wish online:

How a simple solution alleviated a complex problem Tue, 30 Oct 2018 00:00:00 +0100 Estimated reading time: < 5 minutes. Target audience: developers and product owners.

First, a word about software development

Over time, every software goes into maintenance; minor features might get developed, bugs are fixed and frameworks get upgraded to their latest versions. One of the potential side effect of this activity is "regression". Something that used to work suddenly doesn't anymore. The most common way to prevent this is writing tests and running them automatically on every changes. So everytime a new feature is developed or a bug fixed, a piece of code is written to ensure that the application will, from that moment on, work as expected. And if some changes break the application, the failing tests should prevent them from being released.

In practice however, it happens more often than not, that tests get overlooked... That's where it all started.

The situation

We maintain an application built with Symfony. It provides an API for which some automated tests were written, when it was first implemented years ago. But even though the application kept evolving as the years went by (and its API started being used by more and more third-party applications), the number of tests remained unchanged. This slowly created a tension, as the importance of the API's stability increased (as more applications depended on it) and the tests coverage decreased (as new features were developed and no tests were written for them).

The solution that first came to mind

Facing this situation, my initial thoughts went something like this :

We should review every API-related test, evaluate their coverage and complete them if needed!

We should review every API endpoint to find those that are not yet covered by tests and add them!

That felt like an exhaustive and complete solution; one I could be proud of once delivered. My enthusiasm was high, because it triggered something dear to my heart, as my quest to leave the code cleaner than I found it was set in motion (also known as the "boy-scout rule"). If this drive for quality had been my sole constraint, that's probably the path I would have chosen — the complex path.

Here, however, the project's budget did not allow to undertake such an effort. Which was a great opportunity to...

Gain another perspective

As improving the test suite was out of the picture, the question slowly shifted to :

What could bring more confidence and trust to the developers that the API will remain stable on the long run, when changes in the code will inevitably occur?

Well, "changes" is still a little vague here to answer the question, so let's get more specific :

  • If a developer changes something in the project related to the API, I trust that he will test the feature he changed; there's not much risk involved in that scenario. But...
  • If a developer changes something in the project that has nothing to do with the API and yet the change may break it, this is trouble !

The biggest risk I've identified to break the API inadvertently, by applying (seemingly) unrelated changes and not noticing it, lies in the Symfony Routing component, used to define API's endpoints :

  • Routes can override each other if they have the same path, and the order in which they are added to the configuration files matters. Someone could add a new route with a path identical to an existing API endpoint's one and break the latter.
  • Upgrading to the next major version of Symfony may lead to mandatory changes in the way routes are defined (it happened already), which opens up the door to human errors (forgetting to update a route's definition for example).
  • Routes' definitions are located in other files and folders than the code they're related to, which makes it hard for the developer to be conscious of their relationship.

All of this brings fragility. So I decided to focus on that, taking a "Minimum Viable Product" approach that would satisfy the budget constraint too.

Symfony may be part of the problem, but it can also be part of the solution. If the risk comes from changes in the routing, why not use Symfony's tools to monitor them ?

The actual implementation (where it gets technical)

The command debug:router lists all the routes' definitions defined in a Symfony application. There's also a --format argument that allows to get the output as JSON, which is perfect to write a script that relies on that data.

As for many projects at Liip, we use RMT to release new versions of the application. This tool allows for "prerequisites" scripts to be executed before any release is attempted : useful to run a test suite or, in this case, to check if the application's routing underwent any risky changes.

The first requisite for our script to work is to have a reference point. We need a set of the routes' definitions in a "known stable state". This can be done by running the following command on the master branch of the project, for example:

bin/console debug:router --format=json > some_path/routing_stable_dump.json

Then it could go something like this :

  1. Use the Process Component to run the bin/console debug:router --format=json command, pass the output to json_decode(), store it in a variable (that's the new routing).
  2. Fetch the reference point using file_get_contents(), pass the output to json_decode(), store it in a variable (that's the stable routing).
  3. Compare the two variables. I used swaggest/json-diff to create a diff between the two datasets.
  4. Evaluate if the changes are risky or not (depending on the business' logic) and alert the developer if they are (and prevent the release).

Here's an example of output from our script :

Closing thoughts

I've actually had a great time implementing this script and do feel proud of the work I did. And besides, I'm quite confident that the solution, while not perfect, will be sufficient to increase the peace of mind of the project's developers and product owners.

What do you think? Would you have an another approach? I'd love to read all about it in the comments.

Drupal Europe 2018 Mon, 29 Oct 2018 00:00:00 +0100 In 2017, Drupal Association decided not to host a DrupalCon Europe 2018 due to waning attendance and financial losses. They took some time to make the European event more sustainable. After this, the Drupal community decided to organise a Drupal Europe event in Darmstadt, Germany in 2018. My colleagues and I joined the biggest European Drupal event in October and here is my summary of few talks I really enjoyed!


By Dries Buytaert
Track: Drupal + Technology
Recording and slides

This year, Dries Buytaert focuses on improvements made for Drupal users such as content creators, evaluators and developers.

Compared to last year, Drupal 8 contributions increased by 10% and stable modules released by 46%. Moreover, a steady progress is noticeable. Especially in many core initiatives like the last version of Drupal 8 which is shipped with features and improvements created from 4 core initiatives.

Content creators are the key-decision makers in the selection of a CMS now. Their expectations have changed: they need flexibility but also simpler tools to edit contents. The layout_builder core module gives some solutions by enabling to edit a content inline and drag-and-dropping elements in different sections. The management of medias has been improved too and there is a possibility to prepare different “states” of contents using workspaces module. But the progress doesn’t stop here. The next step is to modernize the administrative UI with a refresh of the Seven administration theme based on React. Using this modern framework makes it familiar to Javascript (JS) developers and is building a bridge with the JS community.

Drupal took a big step forward for evaluators as it provides a demo profile called “Umami” now. Evaluators have a clear understanding of what kind of websites can be produced by Drupal and how it works by navigating through the demo website.
The online documentation on has also been reorganized with a clear separation of Drupal 7 and Drupal 8. It provides some getting-started guides too. Finally, a quick-install link is available to have a website running within 3 clicks and 1 minute 27 seconds!

Developers experience has been improved as well: minor releases are now supported for 12 months instead of the former 4 weeks. Teams will have more time to plan their updates efficiently. Moreover, Gitlab will be adopted within the next months to manage the code contributions. This modern collaborative tool will encourage more people to participate to projects.

Regarding the support of the current Drupal versions, Dries shares that Symfony 3, the base component of Drupal 8 will be end-of-life by 2021. To keep the CMS secure, it implies to be end-of-life by November 2021 and Drupal 9 should be released in 2020. The upgrade from Drupal 8 to Drupal 9 should be smooth as long as you stay current with the minor releases and don’t use modules with deprecated APIs.
The support of Drupal 7 has been extended to November 2021 as the migration path from Drupal 7 to Drupal 8 is not stable with multilingualism yet.

This is a slide from Driesnote presentation showing a mountain with many tooltips: "Drupal 8 will be end-of-life by November 2021", "Drupal 7 will be supported until November 2021", "Drupal 9 will be released in 2020", "Drupal 8 became a better tool for developers", "You now have up to 12 months to upgrade your sites", "Drupal 8 became much easier to evaluate", "We've begun to coordinate the marketing of Drupal", "Drupal 8 became easier to use for content creators", " is moving to GitLab very soon".
Slide from Driesnote showing current state of Drupal.

Last but not least, DrupalCon is coming back next year and will be held in Amsterdam!

JavaScript modernisation initiative

By Cristina Chumillas, Lauri Eskola, Matthew Grill, Daniel Wehner and Sally Young
Track: Drupal + Technology
Recording and slides

After a lot of discussions on which JS framework will be used to build the new Drupal administrative experience, React was finally chosen for its popularity.

The initiative members wanted to focus on the content editing experience. This affects a big group of Drupal users. The goal was to simplify and modernize the current interface. Furthermore, embracing practices that are familiar to JS developers so they can easier join the Drupal community.
On one hand, a UX team ran some user tests. Those showed that users like the flexibility they have with Drupal interface but dislike its complexity usually. A comparative study was ran to know what has been used in other tools or CMSs too. On the other hand, the User Interface (UI) team worked on the redesign of the administrative interface and built a design system based on components. The refreshment of the Seven administration theme is ongoing.
Another group worked on prototyping the User Experience (UX) and User Interface (UI) changes with React. For instance, if an editor quits a page without saving they's last changes, a popup appears to restore the last changes. This is possible due to contents stored to the state of the application.

You can see a demo of the new administrative UI in the video (go to 20 minutes 48 seconds):

Demo of the new administrative UI in Drupal 8

If you are interested, you can install the demo and of course join the initiative!

Drupal Diversity & Inclusion: Building a stronger community

By Tara King and Elli Ludwigson
Track: Drupal Community

Diversity in gender, race, ethnicity, immigration status, disability, religion etc. helps a lot. Proven it makes a team more creative, collaborative and effective.

Tara King and Elli Ludwigson who are part of the Drupal Diversity and Inclusion team presented how Drupal is building a stronger and smarter community. The initial need was to make Drupal a safer place for all. Especially for the less visible ones at community events such as women, minorities and people with disabilities.
The group addressed several issues, such as racism, sexism, homophobia, language barriers etc. with different efforts and initiatives. For example, diversity is highlighted and supported in Drupal events: pronoun stickers are distributed, #WeAreDrupal hashtag is used on Twitter and social events are organized for underrepresented people as well. Moreover, the group has released an online resource library, which collects articles about diversity. All of this is ongoing and new initiatives were created. Helping people finding jobs or attracting more diverse people as recruiters are only two to name.

Flyer put on a table with the text "Make eye Contact. Invite someone to join the conversation. Consider new perspectives. Call out exclusionary behavior. Be an ally at Drupal events."
Diversity and Inclusion flyer, photo by Paul Johnson, license CC BY-NC 2.0
Sign mentionning "All-gender restrooms" at Drupal Europe venue.
All-gender restrooms sign, photo by Gábor Hojtsy, license CC BY-SA 2.0

If you are interested in the subject and would like to be involved, there are weekly meetings in #diversity-inclusion Drupal Slack channel. You can join the contrib team or work on the issue queue too.

Willy Wonka and the Secure Container Factory

By Dave Hall
Track: DevOps + Infrastructure

Docker is a tool that is designed to create, deploy and run applications easily by using containers. It is also about “running random code downloaded from the internet and running it as root”. This quote points out how it is important to maintain secure containers. David Hall illustrates this with practical advice and images from the “Willy Wonka and the chocolate factory” movie. Here is a little recap:

  • Have a light image: big images will slow down deployments and also increase the attack surface. Install an Alpine distribution rather than a Debian which is about 20 times lighter;
  • Check downloaded sources very carefully: for instance, you can use wget command and validate checksum for a file. Plus you can scan your images to check vulnerabilities using tools like Microscanner or Clair;
  • Use continuous development workflows: build a plan to maintain your Docker images, using a good Continous Integration / Continous Delivery (CI/CD) system and document it;
  • Specify a user in your dockerfile: running root on a container is the same as running root on the host. You need to reduce the actions of a potential attacker;
  • Measure your uptime in hours/days: it is important to rebuild and redeploy often to potentially avoid having a compromised system for a long time.

Now you are able to incorporate these advice into your dockerfiles in order to build a safer factory than Willy Wonka’s.

Decoupled Drupal: Implications, risks and changes from a business perspective

By Michael Schmid
Track: Agency + Business

Before 2016, Michael Schmid and his team worked on fully Drupal projects. Ever since they are working on progressive and fully decoupled projects.
A fully decoupled website means that frontend is not handled with Drupal but with a JS framework such as React. This framework is “talking” to Drupal via an API such as GraphQL. It also means, that all interactions from Drupal are gone: views with filters, webforms, comments etc. If a module provides frontend, it is not useable anymore and needs to be somehow re-implemented.
When it comes to progressive decoupled websites, frontend stack is still built with Drupal. But some parts are implemented with a JS framework. You can have data provided by APIs or injected from Drupal too. The advantage is that you can benefit from Drupal components and don’t need to re-implement everything. A downside of it are conflicts with CSS styling and build systems handled on both sides. Therefore you need to have a clear understanding of what does what.

To be able to run such projects successfully, it is important to train every developer in new technologies: JS has evolved and parts of the logic can be built with it. We can say that backenders can do frontend now. In terms of hiring it means, you can hire full stack developers but also JS engineers. Attracting more developers as they love working with JS frameworks such as React on a global level.

Projects are investments which continue over time and expect failures at the beginning. These kinds of projects are more complex than regular Drupal ones, they can fail or go over budget. Learn from your mistakes and share them with your team in retrospectives. It is also very important to celebrate successes!
Clients request decoupled projects to have a faster and cooler experience for users. They need to understand that this is an investment that will pay off in the future.

Finally, fully decoupled Drupal is a trend for big projects and other CMSs are already using decoupled out of the box. Drupal needs to focus on a better editor experience and a better API. There might also be projects that require simple backend edition instead of Drupal.

Hackers automate but the Drupal Community still downloads updates on or: Why we need to talk about Auto Updates

By Joe Noll and Hernani Borges de Freitas
Track: Drupal + Technology
Recording and slides

In 2017, 59% of Drupal users were still downloading modules from In other words, more than half of the users didn’t have any automatisation processes to install modules. Knowing that critical security updates were released in the past months and it is only a matter of hours until a website gets potentially hacked, it comes crucial to have a process to automate these updates.
The update can be quite complex and may take time: installing the update, reviewing the changes, deploying on a test environment, testing either automatically or manually and deploying on production. However this process can be simplify with automation in place.

There is a core initiative to support small-to-medium sites owners that usually are not taking care of security updates. The idea is a process to download the code and update sources in the Drupal directory.
For more complex websites, automating the composer workflow with a CI pipeline is recommended. Everytime a security update is released, the developer pushes it manually in the pipeline. The CI system builds an installation containing the security fix within a new branch. This will be deployed automatically to a non-productive environment where tests can be done and build approved. Changes can be merged and deployed on production afterwards.

A schema showing the update strategy through all steps from a CI pipeline
Update strategy slide by Joe Noll and Hernani Borges de Freitas

To go further, the update_runner module focuses on automatizing the first part by detecting an update and firing up a push for an update job.


Swiss Drupal community members cheering at a restaurant
Meeting the Swiss Drupal community, photo by Josef Dabernig, license CC BY-NC-SA 2.0

We are back with fresh ideas, things we are curious to try and learnings from great talks! We joined social events in the evenings too. Therefore we exchanged with other drupalists, in particular with the Swiss Drupal community! This week went so fast. Thank you Drupal Europe organizers for making this event possible!

Header image credits: Official Group Photo Drupal Europe Darmstadt 2018 by Josef Dabernig, license CC BY-NC-SA 2.0.