It’s no shock to anyone that we’re in the age of subscriptions. Our entire world has been Netflixified, with every service wanting a piece of the action. The average person in 2020 had a baffling twelve subscriptions each, with this number only continuing to rise. 

Gone are the days when you could just buy a video game, rent a movie, or purchase a piece of software. No, instead, you have to subscribe. Now, I hear you shouting at whatever screen you’re looking at, “Aren’t you the co-founder of a software that bills its customers monthly?!” 

And, to be fully transparent, yes. However, you can criticise a system while still being entrenched in it (at least, that’s what I tell myself so I can sleep at night). But you know what we don’t do at Prezly? Make it really freaking annoying to cancel our service.

People are dumping their news subscriptions – here’s why

I’ve written previously about how newsrooms worldwide are closing down left and right. This is partly because ad revenue is not lucrative enough to sustain operational costs despite having egregiously obnoxious ad placements. 

I mean, just look at this shit (and this is Forbes):

But the other part? People are rapidly cancelling their subscriptions, which media corporations desperately rely on to supplement ad revenue and create a consistent income stream. For example, just in the United States alone, digital and print media subscriptions have dramatically decreased in the past two decades, according to the Pew Research Center. Daily newspaper subscriptions that were once in the lofty 60 millions are now at an abysmal 20.9 million.

Just some of the reasons people cancel their services include:

• Increasing costs – Subscriptions for newspapers and magazines have skyrocketed, like the 19% price increase in UK digital news subscriptions since last year. ​ With the economic downturn, the average person has significantly less spending power to invest in unnecessary purchases like paid media, especially when they can get a lot of the same information faster and for free through social media (though you could argue you do pay for this with your attention and soul).
• Declining quality – With newsrooms cutting budgets, there are fewer journalists, and the remaining ones are often expected to do more work for less money. Readers now have significantly decreased access to high-quality local news and deep investigative research stories, while publishers simply cannot afford to fund good journalism.
• Churnalism – Many news stories just regurgitate other people’s news stories rather than carry out original research and investigation, largely thanks to the aforementioned budget cuts and the speed at which information moves these days. Media has become far more reactive than proactive in telling stories, both locally and globally.
• Too much pop culture – Digital news outlets don't have the resources or bandwidth to post things that don't have wide-reaching relevance or interest. This often means that they appeal to the lowest common denominator in the form of celebrity culture. Many news readers simply don't care to pay for petty pop-culture drama.
• Media bias – Too many news outlets have become aggressively beholden to their stakeholder and investor interests. This bias seeps out in subtle and not-so-subtle ways, including what stories get told and the general slant of how information is imparted to readers. If you don't happen to politically or socially align with that framing, it can be alienating, if not downright infuriating.

And on and on. There are a million reasons why people are leaving their news subscription services. These cancellations are made even more interesting by the fact that news outlets are making it horrendously difficult to cancel. 

Sometimes, cancelling isn’t so easy

A 2021 media survey found that only 41% of American news outlets allowed their subscribers to cancel online. The other 59% required jumping through hoops, often requiring subscribers to engage in some form of in-person contact. This typically entails a phone call or chat conversation where an aggressive salesperson does everything in their power to make sure you don't cancel. They lob discounts, shame tactics, or other “customer retention” psychological hacks to keep people locked in and paying.

A Redditor complains about this practice:

Decided to cancel my New York Times subscription today and to do so you have to open a chat with a representative. Had to wait in a queue for several minutes to get one, then had to explain why I wanted to cancel my subscription and repeat that I wanted to cancel my subscription. At the end of all this, my subscription wasn’t even canceled, my “request is pending,” so I have to follow up again. Seems uncool that a company can make it this difficult for you to stop giving them money every month.

So, after going through all the work of contacting somebody and explaining the situation, news services are deliberately making the process of cancelling slow, inconvenient, and annoying.

Radek | velvetshark.eth on Twitter / X

Why “dark patterns” are awful for media services

To be fair, difficult cancellations are not a problem unique to news subscription services. Plenty of other services, such as gyms and ISPs, make it difficult, too. It's such an issue that governments are starting to get involved, such as the recent recommendation by the United States Federal Trade Commission to create mandatory “click to cancel” regulations and the European Union’s provisional Digital Services Act.

Until governing bodies get more proactive about solving this problem, it's down to the consumers to navigate these infuriating cancellation systems. In the meantime, corporations, including news organisations, are making millions of dollars per year, banking (literally) on you getting so annoyed that you just give up trying to cancel. 

And please don't be mistaken – none of this is accidental. The inability to cancel subscriptions actually has a term: dark patterns or “deceptive design patterns”.

dark pattern (also known as a "deceptive design pattern") is "a user interface that has been carefully crafted to trick users into doing things, such as buying overpriced insurance with their purchase or signing up for recurring bills".^[1][2][3] User experience designer Harry Brignull coined the neologism on 28 July 2010 with the registration of darkpatterns.org, a "pattern library with the specific goal of naming and shaming deceptive user interfaces
​​
​Wikipedia - Dark Patterns

And in the case of media services that means intentionally confusing user account settings, and, impossible-to-cancel subscription services.

Needless to say, consumers absolutely hate being tricked out of their money by sketchy business practices. It’s become such a loathed phenomenon that websites have even begun tracking atrocious examples of this specific type of user manipulation.

While you might expect dark patterns from dodgy mobile apps or other seedy services, it feels like a bit of a slap in the face when the world’s most prominent newspapers play these stupid cancellation games.

Gráinne on Twitter / X

Dark patterns erode trust in the industry, and it has to stop

Throughout much of its history, journalism has been a respected institution. At a time when trust in journalism is at an all-time low, the last thing media outlets should be doing is trapping people in their subscriptions.

Media corporations using dark patterns are tacky. They’re manipulative. And while we can hope that some legislation will make this a thing of the past, it’s worth remembering the outlets that never stooped to this behavior even when it was all the rage – and those that did. 

Was watching this @leeerob video on How Vercel builds Vercel and had some thoughts.

(shameless plug: I did a How Prezly uses Prezly to run Prezly post a few years back)

Monitoring App

Around minute 8 Rob demonstrates a monitoring tab that we don't have in our vercel account. I'm curious on how to access that feature but also how it's built. It looks a lot like the charts we're seeing in Grafana which is the tool we're using to monitor logs.

Using Contentful

Surprised to learn they are using Contentful and are seeing similar build times of 9+ minutes and a nice way to preview content before they hit 'publish'

I'd love to understand their motivation around using Contentful vs a self-hosted option but what I am particularry interested is the way they preview content. From the screen share I think I can see that they are not using Contentful Live preview but are leveraging their menu-bar which knows that a user is logged in and can therefore load the content from the contentful preview API in addition to having static generation on site build. Nice!

Personally I am considering replacing Contentful with PayloadCMS but still experimenting with it.

Gijs Nelissen on Twitter / X

Feature Flags

To test features before they go live or to gradually roll out new functionality Vercel is using the concept of feature flags powered by LaunchDarkly. At Prezly we have our own self-built solution which is nothing more than a JSON data column that is available on user and company entities.

Now if I want to test a feature flag in production I have to open our admin tools and enable it for that user or account to then refresh the page (and refetch user context).

I like the menu-bar that allows admins to enable or disable features on the fly which is a great, and easy to build, add-on that can save us all quite some time.

My overall feeling of watching the video is that we're doing quite well. It was great to hear that even companies like Vercel have tech debt (still on app + pages router). ​
​​
​Additionally i discovered that most things Rob talks about in the video are concepts we have applied at Prezly oftentimes without using Vercel components though.

Anything you learned from Rob's video?

You know the deal: you want to read about the latest horrifying global event, so you click on the first link, and… it’s paywalled. You go back and click on the second link. Also paywalled (and screaming at you about your ad blocker). Onto the third and fourth articles. Eventually, the global conflict has resolved itself before you find out what the hell is going on.

This is just one symptom of a much larger and more complicated problem: media monetisation. Most of the global media industry is bleeding money and has been disrupted almost beyond recognition. So, how did we end up here? Where are we going? Who broke this system, and how can we un-break it? 

I may not have all the answers, but I definitely have a lot of questions.

What is media monetisation?

First, let's establish a baseline. What is media monetisation? Media monetisation is all about who pays for the media and why. Because the media and entertainment industry is valued at a global $660 billion dollars annually, this is an incredibly large, nuanced, and complicated subject. But it’s also a very important one, because the media doesn’t exist in a vacuum. Public opinion and global policy are shaped by the media that people consume, and biased media can have life and death consequences.

Media bias is one of the biggest side effects of this monetisation question, because as the adage goes, if you aren’t paying for it, you’re the product. 

Who is paying for the media you consume, and why are they paying for you to consume it? Why would these individuals and corps spend millions, if not billions, getting their perspectives in front of your eyes? Is it possible for media to be unbiased at this point, or are we, as consumers, just expected to unquestioningly consume whatever media is most ideologically aligned with our existing viewpoints? Is this healthy, or is it just further radicalizing and entrenching people in their echo chambers?

Media monetisation is a huge issue. But it didn't used to be. And it doesn’t have to be. Before we can realistically talk about what the media could look like in the future, let’s first look at where we’ve come from.

The history of media monetisation: from the 1600s to now

The legacy of digital media history is far more nuanced than I can cover in one article. However, having an overview of history will establish a starting point to talk about how media monetisation has evolved up to the present day.

Pre-newspapers (pre-1600s)

Before printed newspapers, most news was dispersed through word-of-mouth, town criers, or bulletins in city squares. This method was inefficient. Maybe you heard that your lands were being overtaken by some neighboring empire beforehand. Perhaps you found out when an army was knocking at your door and setting your roof on fire. Either way, the news dissemination was slow, chaotic, and rife with human error, fake news, and mistranslation (kind of like how Facebook is now, if we think about it).

Early newspapers (1600s–1700s)

With the invention of the printing press in the 1450s, mass media was on the brink of becoming a real possibility. By the 1600s, newspapers were popping up throughout Europe, with the Relation aller Fürnemmen und gedenckwürdigen Historien first circulating in 1605. This was thought to be the first bona fide newspaper, but others quickly started circulating worldwide.

Something you may not know if you personally do not own a 1600s printing press, but they are expensive and extremely annoying to operate. The average media consumer did not have a ton of fun money sitting around to invest in print media. So, early newspapers were often funded by political institutions and governmental bodies, and aimed more towards wealthy elites.

Because corruption and propaganda are not new concepts, these Ye Olden Timey papers were often more tools of the state than actual, unbiased news. Think about it: what incentive does a governing body have to be objective when they are the ones paying for the information that is being disseminated? That was a good question in the 1600s and it remains a good question now.

Advertising (1800s–1900s)

The earliest newspapers didn't really have an infrastructure for advertisements. Not that they necessarily needed to, because they were basically propaganda rags. In the 1800s, newspapers realized that they could both propagate and profit through newspaper advertisements. Display ads started popping up to offset the costs, and are still prolific today in both digital and physical media formats.

The 1800s saw newspapers becoming increasingly prominent in society. Literacy started going up, as did newspaper readership and advertiser revenue. It turns out that being able to read the ads directly correlates to their efficacy. The “penny press” news began being circulated in 1830, which made for much cheaper papers, offset by ads and available to even the average person.

Subscriptions (late 1800s–present)

The late 1800s also saw a rise in the subscription model of print media. Folks could sign up for a regular subscription and receive a copy of the paper regularly delivered to their homes. This model existed as the status quo news model for a very long time and still exists today, but has largely moved online, where websites paywall the news behind a subscription model.

Subscriptions ensured that people got the news, whether they wanted it that day or not. This has become a standard practice and revenue generator for media all around the world ever since. Subscriptions, advertisers, big interest donors, and lobbyists all work in tandem to make the rapidly globalized news system function, and regular subscriptions act as a stabilizing force for small newspapers and large media conglomerates.

Classifieds (early 20th century–2000s)

While classified ads have technically been around since the mid-1700s, they only took off in the early 20th century. But once they did, boy, did they take off. Businesses and individuals alike were able to pay a small fee to list their offerings and find buyers and customers. There were even personal ads that acted as the analog Tinder and job-posting advertisements that served as the OG LinkedIn.

Classified ads were a brilliant move. Newspapers could help connect people with a broad readership that wasn't available before the internet, and they collected a monetary fee for every single ad posted. The classified ads section was often pages long, with all those classified ads acting as additional revenue for the newspapers. It's hard to adequately articulate exactly how important classified ads were because they fell out of favor so dramatically, but classifieds were massive revenue generators for newspapers, often accounting for up to 70% of their total revenue.

Eventually, classifieds were overtaken by more modern approaches, like Craigslist and Facebook Marketplace. Craigslist and, to a lesser extent, sites like eBay acted as massive industry disruptors, devaluing the newspaper industry by billions very rapidly. You'd be hard-pressed to find a bona fide classified ad these days, and the annual revenue of classifieds dropped 92% from 2001 to 2011 (and it’s only continued to decline).

Digital advertising (1990s–present)

As newspapers went online, so did their ads. The transition was inevitable as more people joined the web. In a lot of ways, this was a good thing. Environmentally, a lot less paper was wasted. The news could also travel faster and update more frequently, which in theory meant more accurate information. (Oh what fools we were.) 

However, many terrible things also happen to the media industry. Local news started dying, with over 2,200 local newspapers closing from 2005 to 2021 in the States alone . Classified ads started disappearing (as previously mentioned), and people began canceling their print subscriptions. This was the death knell for many small, local, independent news outlets.

Ad blockers were another significant blow for the industry as news outlets attempted to subsidize a loss of classified and print ad revenue. If you’ve ever been on a news website without an ad blocker, you’ll know it’s quite the experience.

The move to digital has been devastating for newspaper revenue. Even without a paywall, a print reader is worth 228x more than a digital reader. News outlets everywhere had to aggressively cut back on their more expensive content, like investigative pieces, in favor of smaller, more digestible, more reactive media. Ads were everywhere and ad blockers cost potential revenue to the tune of tens of billions per year (not just for news outlets, but definitely also for news outlets). 

Paywalls (2000s–present)

The early 2000s was the Wild West of the Internet. Online, people could find (or steal) practically anything; the only real limitation was the atrocious internet speed. Newspapers eventually realized that advertisements were simply not going to generate enough revenue to keep operating, especially with the proliferation of the aforementioned scourge of the media industry: ad blockers.

As ad blockers became more common, the paywall was born. They pop up in all forms of media. Netflix paywalls movies. Audible paywalls books. And news sites paywall whatever insane thing a world leader had to say that day (any world leader, take your pick). Because of this global shift to housing all news and comms on the internet, people became more primed than ever to pay for subscriptions (and a lot of them). 

Some news organizations found revenue in this subscription model (such as the Wall Street Journal), but many others continued to flounder and eventually shutter. As more and more media becomes subscription- and paywall-locked, consumers are beginning to push back on being nickel and dimed for every conceivable online service. 

Membership and donation models (2010s–present)

Similar to the paywall, news agencies are beginning to play around and explore different donation models. This is more common in smaller publications with loyal readerships or within nonprofit industries. Additionally, writers and journalists are starting to paywall their own content and thought leadership through newsletters and services like Substack and Patreon. 

Consumers are less likely to receive their media from traditional sources, even when those sources can be accessed online, than in the past. A recent Pew Research study found that people are slowly but surely turning to search engines, social media, and podcasts to get their news over dedicated news sites and apps. While news sites and apps are still the primary go-to, they’re increasingly losing their lead to social media, podcasts, and other forms of microblogging.

Additionally, revenue for news services is dropping almost across the board. Few newspapers have been able to successfully maintain (or even grow) in this current news business climate. Newspaper revenue overall has dropped over 15% just since 2017, and the industry doesn’t seem to be doing much to adapt.

The elephant in the room: owners, private donors, and interests

Up to this point, we've discussed how newspapers fund themselves. But this is only part of a bigger picture. You can’t realistically talk about media monetisation without discussing the impacts that revenue sources have on what gets discussed and why. 

Private donors, partisan groups, government entities, and lobbyists have political and social stakes in what news gets covered and how. Even advertisers often have strong, vested interest in what gets discussed and what doesn't. It's hard to be entirely unbiased when your next paycheck comes from a company that doesn't want you to run a particular story or tell us a specific narrative.

To be a mindful media consumer, you must know who funds your media and why. Media consolidation has massive implications for partiality and contributes significantly to corporate interest interference and biased reporting.

Some good resources for analyzing media bias and ownership:

• AllSides Media Bias Chart
• Media Bias Fact Check
• Who Owns Your News? The Top 100 Digital News Outlets and Their Ownership
• Ground News

This was the first article in the series where I will analyze the objectively broken media monetisation system. Next, we will discuss alternative media monetisation models. If you have any thoughts, reach out to me on Twitter/X. I’d love to hear them.

'Listen to your customers', 'focus on your clients' problems' – recurring advice you'll recognise from pretty much every startup book on the market. It's solid guidance. And for anyone running a tech company? A persistent challenge.

The problem is that there are so many different information channels, that trying to make sense of them all requires a near inhuman degree of attention, organisation, and consistency. Meanwhile the feedback loop, if neglected for even a short while, disintegrates.

At Prezly, I don't think we're listening to our customers enough.

And because one man's dirty laundry is another's chance to learn how to wash up, I've decided to analyse our current process to try to find ways to close the feedback loop and apply customer insights across all the various parts of our company and product.

Our client feedback toolset

Here is a list of the tools we use when it comes to processing customer feedback:

• Intercom: Live chat and email support
• Slack: Internal team conversations
• Zoom: Calls (both internal and external)
• Notion: Knowledge base
• Vitally: Our customer success CRM
• Productboard: Feature prioritisation and insight processing
• Linear: Project management/delivery

That's quite a few tools and, what's worse, that's not all. Three years ago I wrote a much more detailed post on Reddit about the different tools (and associated costs) we use to run our business.

From conversation to feature

Often the clearest way to depict a process is through a workflow diagram, so that's where I started my dissection.

The yellow section on the left shows all the different sources through which we receive feedback. It could be something a customer complains about on our live chat, a suggestion from a team member in Slack, a customer call, and so on.

In addition to these more continuous insight streams, we also have an archive of notes logged in our customer success CRM (Vitally), and a small database of user research notes that we logged several months ago as part of interviews aimed at solving a positioning challenge.

Processing feature feedback

We try to store all feature-related feedback as notes in Productboard. Those notes are then processed by someone from product, usually either myself or a member of the design team. Every note can include multiple feature ideas, as Productboard lets you highlight different sections of a single note and associate each to a particular feature or feature idea.

Here is an example of a processed note where one insight (a user interview) resulted in three different features ideas.

Organising feature ideas

All those different feature ideas are organized in a huge feature tree that can span different product areas and components. This helps keep things organised and easy to find.

All features automatically get assigned a 'user impact score' based on how you scored the importance of that feature in the initial note. You can also fill in the 'effort score' (i.e. how hard a feature is to build) and stack this against multiple user impact scores (how important it is for your customers) to generate an overall 'prioritization score', which can be very useful for deciding which features to work on when.

These numbers (together with a lot of other meta data) can then be used to slice and dice your feature tree, sort them by importance, and kick off development. That's the idea, at least. Some examples of slicing/dicing/viewing that data:

In reality, I find that we use Productboard much like a filing cabinet that we dip into from time to time when we suddenly remember to do some research.

Turning insights into Specifications/Planning

We have been using Basecamp's Shape-Up method for over a year now at our company, and it has served us well. I recommend having a look for yourself, but long story short, it allows anyone in the wider team to pitch product ideas.

Ideally, those product ideas come out of speaking with customers, using the product for yourself, seeing what a competitor is doing, noticing an evolution in technology, or going through logged customer insights. In actuality, most pitches are the result of a more direct thinking process: 'This would be cool to build, so we should build it!'

To tackle some of this problem, we encourage people to sprinkle their project pitches with insights/feature requests from Productboard. This is particularly relevant to the problem statement part of the pitch, which is best seen through the words of a customer (i.e. Productboard insights).

Often, multiple different feature ideas/insights can be combined into a single pitch. For example, when we decided that we were going to explore automatic story translation (at the time of writing, a work in progress), it was through a combination of 14 insights on various features:

• Feature: Google Translate Integration (6 insights)
• Feature: Make translator accounts free (1 insight)
• Feature: AI-powered translations (4 insights)

If a feature is small enough and easy to build, we will skip the Shape-Up pitching process and plan the work straight in our task management tool, Linear, where the CARE team can pick it up as and when they are able (the CARE team consists of developers and designers not currently assigned to an active project).

Picking which projects to build

I could (and perhaps should) dedicate an entire post on the complexity of the betting session. In our Shape-Up FAQ we try to answer the question for the team

Reading this now I feel that this is missing some specifics. Here are all the things that go into betting:

• What are the most important problems?
• Team allocation/holiday?
• Is this project something 'exciting' we can do marketing with?
• How long has this problem been lying around?
• Is there any time-pressure to pick this project now?

We've recently opened the betting sessions from a 2-person co-founder meeting, to a 4-person recorded betting session. That recording is then shared with the team and notes are shared with the authors of pitches that were discussed during that betting session.

The development stage

This could be a blog post all of itself, but to keep things brief: we use Linear to organise our work. We have different teams in product and every picked Shape-Up project gets its own project in Linear.

With a few exceptions, we prefer short projects usually spanning a two-week cycle. During the execution of the project, the team assigned to it writes regular updates that are automatically shared in the relevant Slack channels.

As a rule of thumb, we break projects into separate components that are deployed whenever the team feels there is enough value for our customers. A six-week project, for instance, will ideally have multiple different components going live throughout its timeline.

For features that we're less certain about, we use feature flags to enable their functionality for a subset of customers and see how things progress. If we want more eyes on a feature, we promote it to the 'feature labs' part of our tool so that clients can enable and test it for themselves.

Informing customers

Every time I speak to a customer, I am surprised how little they are aware of our new features. Although we try with our monthly newsletter, a public changelog, an in-app changelog, and a 'what's new' section on the login page, it's clear that we still have a long way to go when it comes to informing our customers about our new features.

Part of this is remembering that people in general feel themselves time-poor, and are unlikely to seek out information – or even open a company newsletter – unless they're really invested in what's going on. It's something we're working on.

When it comes to launching a new feature or an update, it makes sense to contact directly our most relevant audience – i.e. the people who requested that feature in the first place. This is where Productboard again comes in very useful, since it's easy to see any insights linked to a feature request and create a mailing list accordingly.

So we reach out to those people, tell (or better, show) them the new feature, and ask them to try it out and let us know what they think. This is incredibly useful in helping us understand whether we've correctly identified a common customer problem and presented an adequate solution – something that is great after the fact and indispensable during smaller rollouts along the longer six-week project timelines.

On paper, it reads like a solid plan, but even as I write this I'm painfully aware that speaking with customers is the weakest link in our entire feedback flow. Specifically as we're currently struggling with positioning and the question 'what makes Prezly different vs..?' I think that the our the answers are in deeper/better conversations with our customers which we simply don't do it enough.

The challenges

As mentioned in the introduction, I feel that we aren't learning enough from our interactions with customers. It became even more obvious when my colleague Kate started this conversation in our internal Discourse:

I think that a lot of the interactions we have with our customers are one-directional. For example, we invite customers for a user research session mostly because we want to learn what to build. That sounds logical, but it isn't how relationships work.

At no point do we deliberately try to build a partnership where we listen to their challenges, try to come up with the best possible solution, and then return to them to validate and/or iterate.

And there began the idea for this blog post.

Going forward, I want to rethink our process with new requirements:

• Work on the most important problems that our customers face (assuming they fit our mission)
• Always inform customers when we build something they asked for
• Make it easy for anyone to follow up on what happened with their feedback
• Turn insight discussions/debates into company-wide conversations (for people that want to participate)
• Better spot recurring problems and work on those
• Make insights an important input of planned work (context for developers and designers)

With that in mind, I'm going to play around with the Productboard integrations, research what techniques and tools are out there to help us take this to the next level, and share my findings here. My hope is that this approach will help me organise my thoughts as well as bring you into the conversation, and as a byproduct, maybe even save other founders some of this pain.

As always, any advice or experience you want to share – I'm all ears.

Gijs

I've been neglecting this blog and the 112 people that subscribed for updates 🙁 But life took over and just couldn't bring myself to sit down and write. A lot has happened though:

• Decided we're going to stay after the 1 year trial
• Sold our house in Belgium
• We're getting married
• Many of you have visited us (22 visits so far)

We have now been in Spain for 16 months and it has been good for us. We've grown closer as a family and enjoyed a more calm and easy life in the mountain village. I've been hiking the mountains, taking cold showers in the village waterfall and taking the kids to swim/paddle/kanoo in the lake.

But as it goes in life, it's not only happiness and sunshine... We too have our ups and downs: Three kids, our jobs and living apart from family and friends can take it's toll. But overall I can say that I'm happier, calmer and feel mentally and physically healthier being here.

How are the kids?

I know many of you have subscribed to the blog to get an update about the kids so here we go:

• Marcel signed up for basketball and is obsessed. Sinterklaas brought him a basketball ring so he can practice in front of the house. He's also going to guitar classes but doesn't enjoy practicing so it became somewhat of a chore. He loves going to school, made quite some friends and is still his happy self. His strong character is a challenge but we couldn't imagine our lives without our happy clown.
• Lucie is in between being a child without worries and being a small adolescent. After the trauma with the sheep (she found out the hard way how the farm works) she does not visit the farm as often. Small relational struggles (with her friends) at school but all in all she's doing great. On Friday she is going to Teles classes (translates to 'arial fabrics aerobathics') which is basically acrobatics on a long curtain. ​
• Robbert is now officially in puberty with all the behavior that comes with it. Still likes to read books, is playing piano daily (yousician) and is doing great at school where he is learning Spanish/Castilliano. I am slowly introducing him to my type of humor (Hans Teeuwen, Het Eiland, In de Gloria) and he's loving it :-)

After a year we can say that they have adapted the best to the new conditions. They enjoy going to school, laugh/make fun a lot and are learning how to help around the house (as we don't have a washing machine or dryer).

The house

Whenever we can we try to improve the house. I like the Catalan expression 'poc a poc' which is my new motto when it comes to the house renovations

Last summer it was mostly the garden that received most of our attention and we were able to harvest a ton of tomatoes, salad, ​ a truckload of cherries (best I've ever had) and a large variety of herbs and medicinal plants 🌱.

In the kitchen a wood oven made room for a large countertop I tiled myself that now is a multi-functional table for cooking, homework or breakfast. We broke out a small wall to the kitchen to better connect the living room with the kitchen.

The next project is the office area on the top floor. We're waiting for the furniture to arrive so Annelies and I can work from the large office on the top floor with beautiful views. I did speak with her about the rules around interruptions and having calls in a shared office.

(sold) the house in Belgium

After a lot of thinking and rethinking we finally decided to sell our house in Belgium.

When we decided to move we wanted to keep our options open. Also, because the house still had half of our stuff, we decided not to rent it in the first year.

But after using the house over the summer we figured it was time to make a decision. After long conversations we finally decided it was time to let it go. I guess the main reason was that we didn't see ourselves return to that house (it was too small) but a lot of different factors contributed to the decision. And sometimes we still don't know it was the right choice. Time will tell.

After that decision things happened fast...We managed to find some help to fix the place up (repaint some rooms, fix water damage) and each took turns in travelling to Belgium and packing what was left in the house in over 70 cardboard boxes and made plan how to move the piano to Spain.

At the same time we signed up for an Immoweb account and uploaded our best 15 pictures together with a short summary. The first visitors fell in love with the house and decided to buy it. It felt great handing off the torch to a nice couple who reminded us of our spirit when we first moved to that house.

Few pictures just for my own memories:

Getting married

I always said I never wanted to get married. Looking back I'm not sure about the exact reasons but I convinced myself, and everyone around me, that it would never happen. Since we moved to Spain I noticed I've been thinking about it more often.

So I secretly got a ring and waited for the perfect moment to pop the question. Granted, finding the perfect moment took longer than expected as I had told myself that I wanted the kids to be there when I asked Annelies.

But on a sunny day beginning of August, on our way back to Belgium, I went on my knees and asked her. Being nervous and all I forgot to open the box and show the ring. She said yes. And I believe it's the first time in a long time that the kids were speechless for more than a few minutes.

What's next?

We're visiting Belgium for 10 days during Christmas to catch up with family and do the official part of the marriage. As we now don't have a house we're staying in a rental home ​ ​ close to Brussels (Meise) which is great as we're now closer to her side of the family.

When we're back in Spain I'd like to take it easier for a few weeks and clean the schedule. That time will be spent well on skiing, playing guitar and making bread.

Onwards!

If you're in a software or product company I'm sure you have heard the advice of "don't deploy on Friday." This is both reasonable and has merit. However, this isn't great advice in 2023.

By now you've had plenty of time to invest in tooling around your deployment pipeline. I can hear you now, "But Friday is a good day to deploy because everyone is off and I don't have to worry about users seeing my mistakes.", in that case I don't know what to say.

The phrase "Don't deploy on Friday" is shorthand for some sort of a Fridayphobia mantra that has no place in modern product companies. It's an old belief that persists among many developers: deploying on a Friday would bring bad things...

I am going to talk about why this advice came about in the first place, why it's not relevant anymore (there are exceptions), and what can be done instead.

Bugs will be in production longer

The rule came about from a time when deployment was much harder and a big deal. Software teams would plan releases weeks in advance where often big pieces of code were deployed all in one go. Chances to break stuff were significant.

And obviously, we want to make sure that your team can enjoy their deserved weekend and not have to spend their Friday evening debugging just because someone decided to deploy a big change right about when you were packing your bag for a camping trip.

Or maybe the whole process of deploying code is cumbersome and error prone and you don't want to risk having to stay around later and figure stuff out.

Why is this a problem?

One primary drawback of avoiding deployments on Friday is the slowdown in the shipping capabilities. By following a stupid "no-Friday deploy" policy, valuable time on the calendar is lost each week. With each passing Friday, you miss out on the opportunity to deliver value and stay ahead.

Furthermore, avoiding deployments on Friday can contribute to a decrease in team trust. Modern development practices have solved this problem. When a team consistently refrains from Friday deployments, it sends a message that there is a lack of confidence in the overall system.

And although an important component of efficient companies is to be risk-averse that does not apply here. The risk management should be done by breaking up features in workable, deployable chunks that can be deployed and provide learning oppertunities.

In summary, refraining from deploying on Friday will slow the company down and undermine team trust.

The obvious solution - make deployments boring.

The obvious solution, then, is to make deployments constant and robust. You want to make deployment as boring as possible. That way it's a low-barrier activity and a boring process of pushing code to a server and having it run in exactly the same way whether you're deploying on Friday afternoon or at 3 on Monday morning (or any other time).

That means automating every aspect of deployment from start to finish - from triggering the deployment, building the new version of your app in CI/CD, provisioning servers, etc., all the way until making sure everything still works correctly when deployed.

This is the approach we're taking at Prezly which is working pretty well. In addition to a PR review (by another human) we have a set of tests and automation that makes sure everything is working as expected. Additionally, we have a lot of alerts in place that are triggered automatically based on application logs, error codes and speed reports we all capture in our logging datastore. We are able to deploy code dozens of times a day without disrupting users or causing problems.

The advantage of making deployment boring is that product teams start to use that to their benefit where they constantly ship small iterations and improvements instead of large chunks of code.

And although this gets you a long way, it's not a silver bullet. You should never be 100% confident in your deployments just because you have tests.

Easy rollback

Mistakes will happen. The question isn't how often mistakes are made but rather how well they are being handled.

A great CI pipeline should have a 'rollback' button somewhere that switches the application to a previous/working version of the app. This should keep in account any database/schema migrations and have a good mechanism (database migrations) to rollback any changes you made to the database.

Apply the 'no Friday' rule when it makes sense

For the reasons laid out in this post I think the no-shipping-on-friday rule is generally bad, it is important to ackowledge that there can be legitimate exceptions to this rule.

Sometimes there will be changes/improvements/upgrades where there is more uncertainty. Although I'd still argument to try and find a way to decrease that uncertainty ​ there might be a good case to wait for Monday.

Some examples:

• Upgrading the database version. This might introduce unexpected effects that are hard to estimate only by having a good testing suite
• Decommissioning a feature. Lets say you've been testing a whole new layout for the app and are happy with the feedback/experiment by a % of your users. Setting this as a new default and enabling it for all customers might be better on Monday as you can expect an increase in feedback/conversations
• Huge feature releases. Although we try to avoid this there are cases where an event or build-up of a new feature (please don't say AI) will result in an one-off hocus pocus ta-da moment. For any case where you're pushing a large PR/changeset to your production database i think if you have the choice it's better not to do it on Monday.

Conclusion

Now that you know this rule isn't just outdated, it's also counterproductive.

You can take the same approach to deployments that you do with everything else: make them routine, plan for them in advance, and prepare your team for success by eliminating siloed environments and automating as much as possible.

Good reads:

Are Friday Code Deploys Bad for Work-Life Balance? | Built In

Do not deploy on Friday!

“No Deploy Friday” is a sign of IT Maturity

Deploy on Fridays, or Don't. | HackerNoon

Recently I had to answer some data questions around our ideal customer so I needed a way to calculate LTV. In the past I've done my fair share of heavy data lifting to get the most accurate value of Life Time Value.

Alternatively we've used platforms like Baremetrics or ChartMogul to do the math for us. ​ But reality is that we don't obsess over those numbers and just don't look at them enough to account for the cost.

Lacking the data

In our case, calculating lifetime value (LTV) per account is difficult because we don't store historical subscription data. We use Stripe for the bulk of the work, so we mostly just keep track of the current active subscriptions and don't store information about past changes in subscription for each customer.

Additionally we don't have the best insight in Subscribed Acquisition Cost (or CAC) per channel. And even if we did that starts the whole conversation about marketing attribution.

A lot of reasons why we just don't have the best view on our customer Lifetime Value.

A much simpler way

What we do have in our database is a list of all invoices (and credit notes) synced to a single table. It has the history of every outgoing invoice spanning multiple billing systems from something self-built, Xero all the way to Stripe.

The invoices table is looks a little like this where every invoice has a period and is linked to a customer in the customer table.

To get an approximation of Life Time Value I did nothing more than summing up all the invoices per customer which presented me with a pretty good understanding of who are our most valueable customers.

I know this calculation doesn't look ahead and underestimates the LTV. But it did the job of comparing the most valuable customers. Plus, LTV isn't always the perfect solution either.

Some people wield the LTV model as if they were Yoda with a light saber; “Look at this amazing weapon I know how to use!” Unfortunately, it is not that amazing, it’s not that unique to understand, and it is not a weapon, it’s a tool. Companies need a sustainable competitive advantage that is independent of their variable marketing campaigns. You can’t win a fight with a measuring tape.
​​
​From: The Dangerous Seduction of LTV.

With all the commotion around Twitter, Mastodon, and the Fediverse (what is the Fediverse video) I've been reading into the alternatives to centralised and content silos.

Most of my questions were answered by the awesome folks at the indiweb where I was able to update my knowledge about Microformats, syndication, the term 'POSSE', web mentions and indieAuth.

We have a long way to go to replace our current content silos and get back to how the web was intended in the first place. But there are a lot of small and simple things that product builders, content creators and readers can do today to bring us all a little closer:

• Own your own site/content: Buy your own domain name and set up a personal site to own your content. Post it on your site first and share it on socials.
• RSS everywhere: Make sure our blogs/sites support RSS and encourage anyone to install and use an RSS reader. No algorithms, no ads, but updates from the authors and products you want to hear from.
• Subscribe for updates: Provide a form where visitors can leave their email to receive updates. I prefer RSS over that but people less tech-savvy can be informed about new posts and content.
• Support microformats: So other readers/machines can understand/read your content. I wished there were more good arguments to support Microformats but since it's so simple to do I don't see a reason not to.
• Skip the algorithm: Pick the news sources and authors you want to know about and find a way to subscribe to their content.

As a content platform/product builder I have to admit that I feel we could do more to support a more balanced and open web.

This Blog

Owning your own domain is the most important in implementing the IndieWeb. The domain is owned by me personally and the blog is hosted on Vercel but I can move it any time I want. More about how I built this blog. And lately, I've been trying to make sure to post on my website first, and then share links/threads on the social web.

Still, I found that the blog wasn't Indie enough with some issues like:

• RSS feed without the full content
• Lack of microformats
• Unable to 'subscribe for updates' in a specific category

And with a few hours to spare I decided it was time to change that.

Microformats

It took me a few minutes (see commit) to add some tags to the HTML structure to support the most common MicroFormats like `dt-published` and `h-entry`. I also added an h-card to every page.

Strangely enough, the validator at https://indiewebify.me/ is not detecting the micro format tags.

• Validating h-card result
• Validating h-entry result

Needs more investigation.

Update: Tom Morris (maintained of the Python Microparser library) reached out to tell it this is a bug on their side (conflict with Tailwind classes). It's probably a bug against the microformats spec but I don't want to go into this rabbit hole.

(RSS) Feeds

For RSS feeds I implemented an API route to query the Prezly API using the SDK and generating an RSS feed.

API code:

https://github.com/digitalbase/lifelog-nextjs/blob/main/pages/api/rss/index.tsx

The tricky part was how to turn complex content blocks (gallery, embed, images with zoom) generated by the Slate Content Renderer into something that works for dumb(er) RSS readers.

ℹ In case you didn't understand this part. Prezly is using an internal document format (based on SlateJS). The Slate Content Renderer package turns that tree structure into React components to be used whenever the content is displayed.

To address that I ended up creating a SlateFeedRenderer class that dumbed down the content to something that would be supported by non-JS readers.

https://github.com/digitalbase/lifelog-nextjs/blob/main/components/SlateFeedRenderer/SlateFeedRenderer.tsx

This is still a work in progress but I got the images and galleries to work by cutting out extra zoom functionality and replacing it with simple image blocks.

This turned out to be much easier than I expected cloning the original Gallery block and cutting out the extras leaving me with a simple loop that generates <img> blocks.

https://github.com/digitalbase/lifelog-nextjs/blob/main/components/SlateFeedRenderer/components/RssGallery.tsx

Because I decided to use the the Feed package (by @jpmonette) I also implemented an Atom (RSS 1) and JSON feed.

Find the feeds here:

• RSS 2.0
• Atom (RSS 1.0)
• JSON

Lastly, I sprinkled the interface (footer, about page, homepage) with some feed links and gave every category it's own feed.

As a product builder

I will play with this a little more and figure out which of those concepts I need to bring to Prezly. The obvious one is better RSS feeds but there might more things we can do that make the web just a tiny bit more decentralised and Indie.

Good reads:

The IndieWeb for Everyone

Syndicating Posts from Your Personal Website to Twitter and Mastodon · Matthias Ott – User Experience Designer

What is the Fediverse?

Twitter, Mastodon and the Fediverse: I Have Questions

IndieWebifying my Website Part 1 - Microformats and Webmentions

Adopting Basecamps 'Shape-Up' method at Prezly transformed our company. In an introductory video by Ryan Singer (author of the method) he talked about the three main reasons people are interested in the method

1. We're growing. Help me run multiple, parallel product teams
2. We're slowing down. Help us get back to shipping fast
3. There's got to be a better way.

Looking back I think we were struggling with all three. Although we tripled the product team we never really got the performance we knew we could have.

And on the company retreat, someone that recently joined the company asked me if I had ever read or tried Shape-Up which I think she used at a previous company. After coming home I immediately ordered the book and started reading it.

The introduction chapter opened my eyes and I wanted to give it a go before even fully finishing the book. I did take a few more days to process the book and read any additional information I could find.

Just to give you an idea about all big stuff we shipped in the last 3 months:

• Multi-workspace support (anouncement)
• Theme showcase (/themes on website)
• Allowing customers to trial a newsroom (live / not live status)
• Improve the editor (ability to add blocks) (blog post)
• Newsroom Analytics through Plausible Analytics (announcement)
• Snippets (announcement)
• Editor Placeholders (announcement)
• Get rid of the newsroom picker (announcement)
• Comparing Prezly to our competitors on the website (/vs/mailchimp on website)
• Rebuild the gallery feature (announcement)

This is a huge list and I couldn't be prouder of the team and the quality of the work they shipped even though it was the holiday season and our team was severely impacted by the war in Ukraine and events in Iran.

Here are a few things we learned from the book that I hope can help you to ship faster and better.

Stick to the (shaping) process

It's natural for founders and people with influence on the betting process to push for the things they believe in. That is the whole concept of 'the betting process'. But the most important thing is to follow all due steps.

I've caught myself and my co-founder rushing certain pitches and making them ready for betting when they are not. I mean how can we decide to improve the /help section on the website without thoroughly consulting with the Customer Success team? One time I was writing a new pitch on the night before we had the betting session hoping to include my own awesome idea.

Following the process means involving the right people, getting smart people to try and find some gaps in your pitch and giving everyone enough time to provide feedback.

Don't be too negative

It's easy to try and poke holes when you're the first one going in to review a pitch. Be aware that it's often the first time people are formally writing down their idea.

You want to encourage people to write more.

So make sure to find the right tone in your message. My personal communication style is often too short/direct which might gets interpreted as killing the pitch. Don't be that guy!

Be ready to cancel a project

At the beginning of adopting Shape-up, we were oftentimes under or over-shaping the projects. This allowed poor pitches to make it to the product team which is a recipe for failure.

Some signals that there is something wrong with the pitch:

1. Team members are very confused in the beginning (scoping) of the project
2. Open comments/concerns in the pitch that were not addressed by the author
3. A long list of documented Rabbit holes
4. The solution is too vague. 'Build a calendar' or 'Implement a notification system' is not enough direction for the team to act on
5. The assigned team has major concerns/thoughts not addressed in the pitch

At one point we decided to cancel a project a few days after we started it because there were just too many unknowns.

In the meanwhile, this project has been re-shaped and made it through a more thorough review process. And it's live now!

Collaborative Shaping = gold

I found the best pitches to be written by multiple people. It often starts with a rough idea that someone writes down - a problem statement and a concept solution and other people start pitching in with different ways to solve this problem.

Make the team accountable

The whole concept only works if you make the team responsible for the outcome and take away as many distractions as possible. No interruptions.

But accountability works both ways.

(this part sounds passive-aggressive reading it now so let me add some more context). ​
​​
​What I am trying to say is that as a pitch author and voter you have a responsibility to make sure the pitch is coherent, well-defined and generally makes sense.

But as a product team, you have the responsibility of taking that input (the pitch document) as an important guideline and starting point.

In one project we had the team dismiss a key part of the solution. ​ Not only did they drop a part of the solution, but they also didn't communicate that until the end of the project.

When the final project was announced I learned that they felt that one part of the pitch was not critical and too challenging within the appetite (two weeks) of this project. And because we repeated a lot teams can make their own decisions (Chapter 10. Hand over responsability) the team assumed that that was ok. My opinion as an author of the pitch was that it was not ok.

This started an interesting conversation with unanswered questions:

• Can the team leave out parts of the 'solution' part of a pitch?
• Does the author of the pitch need to be consulted in that case?

The answers are probably even more complex because it depends on the pitch itself and how essential this component is to address the initial problem outlined at the start of the pitch.

Once I learned about this I sent some feedback to the team:

Hi team, today (two days before the project is finishing) I learned that you decided to drop a key part of the documented solution.

This is not the way to do it though. The pitch was reviewed by some of you before the project started and that component was a key part of addressing the project's problem statement.

If you want to drop a part of the solution you need to do it at the beginning of the project and properly communicate about it.

Two weeks later I still think this was the right call but I am also more aware that I need to communicate better about why we're working on a pitch and the boundaries of freedom when it comes to the building phase.

In this specific example, we solved it by extending the project by a few days and the team worked on the missing part and completed the full project in 2.5 weeks instead of the 2 allocated weeks. We are still working out how best to communicate scope changes during projects to avoid surprises - it’s a learning experience for all.

Spend enough time on the problem

I've created a template for pitches that provides some format when writing a pitch. It contains 4 chapters: Problem, Solution, Rabbit Holes and No-Gos. But on numerous occasions I found myself crafting a pitch to only spend a few minutes on the problem part of the pitch. But how can you come up with a good solution without fully understanding the problem, to begin with?

It’s critical to always present both a problem and a solution together. It sounds like an obvious point but it’s surprising how often teams, our own included, jump to a solution with the assumption that it’s obvious why it’s a good idea to build this thing. (From the Basecamp book)

I've created a template for pitches that provides some format when writing a pitch. It contains 4 chapters: Problem, Solution, Rabbit Holes and No-Gos. But on numerous occasions I found myself crafting a pitch to only spend a few minutes on the problem part of the pitch. But how can you come up with a good solution without fully understanding the problem, to begin with?

Looking back on all the projects we've been working on I am not 100% sure these are the most impactful things for us to work on. But these were the only pitches that were ready for betting.

ℹ An important part of the betting process should be discussing the importance of a problem and how it's impacting the business. The answer to that question will determine the likelihood of a project being picked. Instead, we find ourselves discussing the pitched solution most of the time without taking enough time to talk about the problem this pitch would be solving.

Secondly, I don't think we have enough ways to remind team members and ourselves to work on the most important company problems. It's much easier to scope a pitch to improve an existing feature than to write a pitch about something experimental with a much larger potential.

In the past, we've been careful with more experimental/wild ideas because we didn't want those projects to get out of control (larger scope, take much longer than anticipated). But with the new approach and the concept of circuit-breaker vs appetite, we need to push ourselves to get back to more daring ideas that might address some of the core issues we've identified for our company.

No-gos are super important

People will try to hijack a project to introduce some changes they always wanted which aren't always tied to the pitch. And that's ok. The whole idea is based on empowering the teams to make their own decisions.

But you want to limit that.

That's why I think it's important to explicitly try and forecast that dynamic and to list things that you do not want to see people go into as part of the project.

We'll continue to make slight adjustments to the way we work while we're exploring how to use this new approach in other parts of the business like Marketing, Sales or Customer Success.

It's been almost three months since we moved to Spain and I figured it was time for an update as the last one is dated from the beginning of September.

We've been busy fixing the house, getting back to our jobs and entertaining guests. In September and October, we had a lot of guests/family over which is awesome but sometimes a little exhausting to try and make sure they have a good time.

Kids & School

We never expected this to be smooth...Going to school in a new country with another culture and language takes some time. On most days the kids are happy and eager to go to school. From time to time, one of them claims they want to go back to Belgium or stay home…but I am not reading too much into it at this point...

After school and during the weekends they are really starting to appreciate the town and the super friendly neighbours. Regular visits to the sheep farm, playing with the dogs outside or taking a cold bath in the small pond in front of the house. Almost always accompanied by Spanish sunshine.

The kids are rapidly learning Catalan and when I asked them yesterday about how much % of what the teacher is saying they understand they all seemed to agree with 50%. Fifty!

Step by step Annelies (but mostly Robbert) is convincing the school that he should be enrolled in the 3rd year and not the 1st. It's been quite a frustrating experience as the school (but mostly the district) did not want to accept the numerous (official) Belgian documentation (letter from the school, exams tests, grades, ...) that Robbert was 2 years ahead of his age group. They finally agreed to test him from which they learned what we were trying to tell them all this time. Starting last week Robbert is now enrolled in part of the 1st and the 3rd year of what they call 'Institut'.
​​
​Both Marcel and Lucie have signed up for Climbing classes at the local sports centre. The first lesson was a great success!

House Renovation

I have to admit I underestimated the work required to make this an awesome place. In Catalan, they would say 'Poc a Poc' but since winter is coming and it's getting colder we found ourselves becoming impatient and slightly frustrated.

With that, we also decided to tile the living room ourselves and to make it worse we chose a small tile where every floor takes forever. We ended up tiling the floor with over 3000 small 5x15cm ceramic tiles. Annelies helped me out a lot, especially with the 2nd part that I didn't catch on the timelapse. Also, notice how in the beginning the kids are excited to help out but they get bored after the first few hours :-)

At the same time, I moved the central heating system to another room in the basement and therefore I had to extend and reconnect all the old copper tubes which ended up taking much longer than expected. Recycling and fitting copper pipes is a time-consuming task!

Now I am learning and reading about how to install an underfloor heating system to an existing (gasoline-based) heating system. Temperature sensors, pumps, manifolds, and three-way zone valves...

Visits to Belgium

This week I'm going back to Belgium for the first time as I need to fix some things in the (old) house and get some time with colleagues and Jesse.

Annelies had to get back to Belgium for her job 2 weeks ago and it looks like she'll be doing more regular visits as for me I'm planning to go once every 3/4 months.

Mushrooms & Pizza

I've started to get into collecting mushrooms in the forest but wasn't able to free up enough time to really get into it. The first trips were very nervous as I didn't really understand which ones were eatable and which ones were toxic. So I learned about the 5 most common types of Catalonia and learned where they grow and how to recognise them. Here is what I found so far:

I always fantasised about building my own wood based pizza oven. In Belgium the garden didn't really allow for it plus maybe busy life and the climate didn't allow us to enjoy that oven to it's fullest. Excuses, excuses. I know.

So coming to Spain I took it to heart to build the perfect pizza oven. I've done my fair share of research (watching youtube videos 😬) about building the perfect pizza oven. But because there is so much work in the house I couldn't prioritise this right now. That is untill I bumped on this video of a guy making a quick pizza oven with a few bricks and a heat resistant plate.

A few hours later, and 30 euros lighter after buying some fire-resistant bricks I put together an even faster/crappier version of this concept.

And after one test run in the very messy garden (left picture) we moved the oven to the small town square. Since then we've had more than 5 open pizza parties with visitors and neighbours. Great stuff!

The two (web) apps I use the most in my day-to-day Prezly work are Notion and Linear. I do prefer their native (Electron based) apps.

Using BetterTouchTool and the Hyper-key I have dedicated keys to switch to those apps. In my case Hyper+L opens Linear where Hyper+N switches to Notion.

But as both apps link to each other a lot and we share a lot of Linear and Notion links through email, slack or other messaging apps they always open in my browser.

BTT to the rescue

I have configured BTT (BetterTouchTool) as my default browser and set up some automation to inspect the URL and launch them in the right browser before falling back to my default browser.

And then I'm using Javascript to launch the right app and pass the URL.

Github Gist: Notion launch.js

Github Gist: Launch Linear.js

This set-up works pretty well. It does not work within the browser though. So if you're clicking Notion/Linear links from a webpage (already in the browser) this automation does not kick in as it does not pass through the OS link handling.

Writing and publishing a blog post or press release is at the core of the Prezly product and we want to make it better, faster, more powerful and easier to use.

But building an editor is bloody hard and in a post last year I listed a number of things I find important when it comes to the writing experience.

Since then we've been spending a lot of time on improving the Prezly editor. One of the ways to measure our progress is to look at the time it takes for our customers to complete the journey from creating the draft to the final publication of that story.

In about 1 year we have decreased the time from an average of 33.8 minutes to 22.6 today. In this post, I am going to highlight the many changes we made.

Adding blocks to a story

One of the main ways to insert anything else than text is to use what we call 'the plus menu' which is a lot of CMS/content editing platforms perhaps like Notion.

We noticed through qualitative and quantitative feedback that some of our customers didn't know that there is a [+] menu in the first place. That's why we improved the empty state and added a tooltip and improved copy to encourage customers to try it.

The [+] plus menu

The menu is a powerful tool to mix text with any of the other blocks that are available in Prezly like galleries, videos, file attachments or regular embeds.

We looked at 100s of sessions of how people were using the + menu and made a lot of small/improvements:

• Improved positioning of the menu on different viewports or when scrolling
• Better (fuzzy) search
• Support alternative keywords (aliases) for blocks. Searching 'youtube' will find the video block
• Added a suggestions menu with the most used/important blocks
• Smarter positioning of the flyout menu (when scrolling). See below.

In-between content

Once you have a story with some content you might want to add some multimedia in the middle. One of the challenges is that the + menu icon only shows up on an empty paragraph. And to add an empty paragraph you need to move your cursor to the beginning or end of a paragraph and hit enter.

This works if it's a paragraph but becomes annoying if you want to add a block between two other blocks and even impossible if the first element in the story is a multi-media block 😱.

Initially, we wanted to solve this with icons that allow you to create an empty paragraph before/after similar to how CKEditor is solving it.

But the prototype we built came with some challenges and looked messy with the existing options/block menu we already have.

We landed on some virtual whitespace before/after a block that can be used to insert a new paragraph.

Keyboard Shortcuts

In addition to a workflow that involves touching your mouse we also added support for keyboard shortcuts:

• Ctrl + Enter (Cmd + Enter on 🍏) to insert below the current block
• Ctrl + Shift + Enter (Cmd + Shift on 🍏) to insert above the current block

The goal is to add additional keyboard shortcuts for common-used actions like inserting a video, linking the selected text, etc...

Component Controls + Placeholders

We cleaned up the UI of the component controls and made them dark. There was a lot of discussion around the dark UI but the main idea that ended up making it was that this way it contrasts with the rest of the editing experience highlighting that the dark menus are extra things/settings you can do with every editor block.

With that, we also touched the text menu and the campaign composer menu to all be dark and provide a consistent editing experience.

Additionally, we made the behaviour to add blocks more consistent where every time you want to insert a block we add a 'placeholder' in the editor. This placeholder can be used to provide more guidance/help links and implement some draggable zones where an image (or multiple images) can be dragged on top of the placeholder.

Pick a site before you start

Because Prezly supports multiple sites it's important to know in which space you are currently editing, because some settings and editing options are tied to the context.

• The available languages/translations are linked to the newsroom settings and defaults
• Newsroom contacts (think Author cards) are tied to the context of the newsroom
• Preview URLs are different

For any customer that had more than one space, we had some magic/hard-to-explain rules and combinations that guessed the site you wanted to create this story in. The problem was that sometimes we guessed wrong which made the editing experience much harder than it should be.

We'd see editors trying to change the language of their story, or insert a contact card that wasn't there. All because we picked the wrong site.

The decision to solve this was quite simple:

1) Pick your newsroom

The idea is to add a little friction to the flow to create a new story but avoid some headaches down the line.

Obviously, customers with only one site don't see this picker.

2) Show which space you're in

Instead of having a super-weird UX pattern where one dropdown (site dropdown) would serve as both a breadcrumb and a 'change your newsroom' flow was utterly confusing.

So we moved the 'change newsroom' to an advanced settings pane and made the site indicator prominent and read-only so there is no more confusion as to which space you're editing in.

Image Uploader

Behind the scenes, we're using uploadcare.com for all uploads like attachments, videos, media galleries and pictures. This is a tremendous help as they provide uploading tools but make it easy to transform and serve those assets through their CDN.

We have a deep integration of Uploadcare within Prezly but the most noticable integration for our customers is the upload modal.

So we looked at a lot of sessions where people were using this modal and came up with a list of improvements:

• Improve copy of the different tabs + text
• Provide quick access to help docs
• Allow reordering image galleries during upload
• Implement a 'recently uploaded' tab to avoid having to upload the same asset
• Shortcuts to set the image description based on the file name
• Bring the UI closer to our design system
• Add a 'newsroom media' tab enabling editors to pick content from their site media kit

We're not done yet. But between now and my previous post on building an editor-friendly writing experience we've made good progress.

• ✅ Auto-save to avoid losing work
• Awesome linking experience
  • Easily link to other content in the same CMS
  • Allow different type of links
  • Highlight (and upgrade) broken links
• ✅ Use good typography
• ✅ Great support for lists
• ✅ Show pasted images inline
• ✅ Essential features done right
• ✅ Wrap long lines
• ✅ Make it fast (speed/performance)
• ✅ Support text-correction extensions
• Undo/Redo (with shortcuts)
• Good pasting behaviour

We're currently working on a new interface for Story editing that goes beyond the Prezly editor (Snowbird). This will hopefully address most of the issues I listed in this previous post.

Are there any improvements you'd like to see?

Another 3 weeks passed by in a heartbeat

Took some time to write a quick update. If you haven't read the previous updates yet you can find them linked below:

• July 2022 Moving to Spain
• August 2022 First week in Spain
• August 2022 Settling In

​So it's been 3 weeks since the last update which I updated to point out that we did find Robbert in the end.

Back to school

On the 5th of September, the day had arrived for Lucie and Marcel to go to their school. Now normally there would be a bus coming to the town to pick up the kids, but obviously (this is Spain) it turned out that that wasn't fully arranged yet.

So Annelies and I drove the kids to school where they'd meet their teacher and this years classmates.

They had a wonderful day although they barely speak any Catalan. They have been enjoying school so far although the teacher has raised some integration/language/behaviour issues with the youngest. He'll come around!

Robbert had a slightly longer summer break but on Wednesday it was his turn to go back to school. Sadly he was forced to go back two years 😞 as the school system here did not accept all the (official) documentation we provided that Robbert finished his 2nd year in Belgium.

Although the school provided an out where they could upgrade him 2 years after they ran some tests we do not have any guarantees that they'll come around. We keep pushing and lobbying to get this fixed...

Every day when I pick up Robbert from school I ask him to score his day. We went from 5/10 to a 7/10 in the course of almost two weeks. As the schools both finish with a 45- minute difference, we have some quality time. It's great to find him in a good mood, and I can see him making new friends. I'm sure he'll be super fast at learning the language having to listen to the teacher talk all day.

I'm so proud of them

Sheep everywhere

The ride up and down from our village is awesome. The sun is out almost every day and today we hit almost 30 degrees.

One day I was late to pick them up as I was caught up behind 300 sheep waiting for them to clear the road.

We spent some more time with the farmer who uses dogs to guard the cuddle and move them around. The kids are enjoying the time with the kids. Marcel told us he might not become a DJ when he grows up but is trading that for becoming a sheep farmer.

Today we watched a lamb being born.

Home Progress

On the home front, there is nothing spectacular to report on. We're trying to make small progress every day which is getting a bit easier with the kids going back to school.

Some stuff we did:

• pumped gasoline tanks to a new location
• turned the gasoline storage room into a chicken coup
• cleaned up the garden and installed a chicken fence. They still escape though
• reinstalled most of the electricity
• cleaned up the basement as a working shed
• restored an old table to use in the living room
• bought and installed a washing machine
• more firewood
• took out more trash (10+ drives to the waste facility)

The next step is to prepare for winter as our heating system isn't functional yet. We're trying to figure out what the best and most realistic way is to heat the house during the winter. This will the most important project for the weeks to come.

We've had a free trial form for over a year now and we're constantly fighting people that sign up to abuse our system.

What happened?

Last weekend someone was able to sign-up for a Prezly trial and send out over 4 million emails unnoticed. I mean, we did notice it after the weekend but then it was too late.

This will increase our SendGrid bill but that's not the worst. It also affects our sending reputation which is slowly recovering after the hotfix on Monday.

TLDR: The 'send a test email' functionality allowed comma-separated multi-send and was hijacked to send out spam (with [TEST] prefix).

How could this happen?

We have a number of limits in place for trial accounts: Any account that has not entered their credit card details can not interact with DNS (newsroom domain, DKIM/SPF sender domain verification) and there are time-based volume limits in place with regard to email sending.
​​
​The truth is that we didn't build these limits for trial accounts but rather for some high-usage customers and found out later that the same validation should be applied to trials.

This weekend on Saturday night we had a ton of incoming trial requests with similar email addresses that looked sketchy. As we've become more confident in the automatic enforcement of account limits we don't manually check logs/verify account activity (anymore).

These trials hijacked the 'send a test email' functionality in the email composer that allows customers to enter a comma-separated list of addresses to send a few people a sample email campaign. The email subject is prefixed with [TEST] - though.
​​
​The spammers abused this feature to enter a very long string of email addresses (up to 10k email addresses per submission) and do that over and over.

After doing more research about what exactly went down I believe later some automation was used where we were seeing multiple accounts exploit the same vulnerability at the same time.

4 million emails. Sigh...

Patching the hole

After Jesse noticed something weird happened over the weekend it took a few lines of code to add additional validation to prevent this from happening. But as we didn't want to remove that functionality we decided that trial users can only send test emails to their own email addresses.

We're aware this is not the perfect solution and some of the higher-quality trial accounts might be annoyed by this limitation.

In the long-term, I think we'll implement some kind of scoring system where those limitations are applied based on some (automated or manual) qualification/risk score.

What else could go wrong?

Taking a step back from this specific case I took some time to think about other potential ways a trial account could harm our system or significantly increase our cost for running Prezly.

Here is what I came up with:

1. Use our newsroom/CDN to host files
2. Overload the system by importing huge/corrupt contact files
3. Use the API to create a huge amount of content increasing our Algolia charges
4. Trigger a shit-ton of `identify()' calls to increase volume-based MTU billing in for example segment.com

Although I am aware that only scenario 1. will provide value to the attacker with more incentives than the other more malicious scenarios, I think this is something to be aware of.

In Scenario 1) we do have some kind of measures where we clean up old/sleeping accounts and thus there would be no long-term benefits of using Prezly as trustworthy file storage.

Going Forward

This case has reminded me again that we should probably do even more to protect our customers and reputation. And while I want to make sure that good leads/PR agencies and brands that sign up for a Prezly trial have an awesome first experience. That experience is impacted by some of the limitations we put in place to protect ourselves from bad actors.

Some ideas and things I will be exploring in the next few weeks. For some of the larger ideas, I will create a Shape-Up/Scoping document and pitch them in the next betting session.

Use our Trial Qualification

We are already manually qualifying all incoming trials in the Prezly app. This allows us to run other automation and playbooks based on the quality of the lead.

As our sales team is manually going through those leads, connecting with them on LinkedIn, and figuring out if this is a real company vs a bot, I think this is a good indicator of how much we can trust those accounts.

We could keep all the trial limitations (and the extra limitation we built in for this spammer) in place for low/unqualified accounts where we get out of the way for trials that were manually marked as having higher potential.

Improve monitoring & Alerts

We only send automated alerts (SMS/slack messages/phone calls) if there are reliability issues with our systems. An increase in error rates, failure to connect with backstream systems, and issues with load or pods crashing.

But we don't proactively monitor and alert customer behaviour. This means that creating 100k stories or importing 5 million contacts would probably go unnoticed unless it would trigger any reliability alerts due to a slower database or the application being unable to keep up.

But because we have some components that auto-scale the damage might already be done before we even notice it.

Going forward I think we need to proactively monitor total system usage with things like:

• Number of emails sent
• Number of stories published
• Number of newsrooms created
• Amount of domains verifications failed
• Total amount/size of uploads on CDN
• Contact import records being processed

After we have some baseline metrics we could set up certain thresholds and alert the right people if the number is exceeding 'normal' app usage. It would probably have helped a lot in noticing this issue a little earlier.

Isolate the email reputation for Trial Accounts

Almost all customers (outside of some Enterprise customers) share the same IPs and email-sending infrastructure. We do a lot to protect our reputation:

• Warning customers of increased spam rates
• Forcing unsubscribes. No way to revert a recipient's unsubscribe
• Dropping soft bounces for future campaigns
• Discouraging 'email all' behaviour
• Suspending accounts that smell like spam

This enabled us to keep our sending reputation high as landing in the inbox is one of the key concerns for new customers trying our product.

But every software has bugs or oversights. And I think it's safe to say there will be similar situations in the future.

So wouldn't it be good to isolate the sending behaviour of trial accounts, and maybe for newly joined customers on lower plans, to their own sending IPs and email reputation?

Ask for Credit Card

Some of my favourite SaaS companies ask for a credit card during the sign-up process and talked about it (Nathan Barry/Convertkit). I am pretty confident requiring a CC would do what you'd expect:

• Lower conversion rate
• Increase usage for trials
• More efficient funnels for trials

And although this would probably discourage bad actors from trying to exploit Prezly it comes with a price. Because now you have fewer trials together with less information on what people do when they are first activating their account.

So I'm not sure about credit cards yet. And this discussion on Indiehackers proves that I'm not the only one with that concern.

In an ideal world, I would not have to spend time on this and focus on building an awesome product and company. Yesterday I learned about Heroku shutting down their free plans stating 'abuse' as the main reason. So I'm sure we're not the only ones struggling with this.

It's been three weeks since we moved to Spain and here is a quick update on how it's going.

Second Visit

This week we welcomed Peter and Ann who were visiting us from the other side of the Pyrenees (Around Toulouse). Although they made a short stop on their way to Tarragona we enjoyed their stay.

I helped Peter find a calm/wild camping spot to spend the night after we had a joyful evening with steaks, wine and lots of laughter (and serious conversation).

The next day we showed them the Village and took them to the lake at the bottom of the mountain.

The first hike - Lost Robbert 😳 

In addition to getting back to work, now that the internet is finally working, we wanted to make it feel like a holiday spending time by doing fun activities and spending family time with the kids.

The first thing we want to do is get familiar with the mountain we're on and its surrounding area. On one of those walks, Marcel convinced the neighbour's dog 'Rudy' to join us on our walk taking us to the local peak of our maintain enjoying a nice pick-nick with a beautiful view.

I promised Robbert we'd be on time for an important online tournament he was following which turned out not to be the best idea. Because of the heat, we were going much slower than anticipated and time was running out for Robbert to make it to his game.

As the walk was following a single path, and Robbert (12 years old) guaranteed me he knew the way back, we allowed him to take a (2km?) hike back ensuring he'd be home on time. After we finished pick-nicking and took our time to get back to the house, we discovered Robbert wasn't home yet. 😟

People in the village came to help us find him (they must think we're dumb city people) and I took the chance to test out how well my off-road pick-up driving skills were. I drove up to the top of the mountain we hiked and found Robbert in a slight panic but not eaten by bears yet :)

On the car ride back he did tell me that he was worried because I told him:

If you get lost on that side of the Pyrennees you can walk for days and not find a single house. People have died getting lost.

I was just trying to make them cautious when they explore the woods. Remember your way back to the house!

Catalan Lessons

So we've been getting family Catalan lessons every second day. We found a great teacher from the village that has an awesome way of teaching us starting with the essential basics for small talk/beginner conversation. It must be hard teaching such a diverse (age-wise) group of students but she's nailing it.

Progress is slow but steady. Annelies and Robbert are the best students in the class and making impressive progress while Marcel is having a hard time being focused for anything more than 15 minutes.

Swimming

The nice thing about this side of the Pyrennees is the availability of water. Lakes, rivers and small ponds. So many places to spend a day in nature while the kids are playing in the water. Someone from the village gave us some tips on the most beautiful spots and on the first attempt, we hit a home run.

We found this awesome place next to the river. It was surrounded by high cliffs, the water temperature was amazing and all throughout the river there were big rocks the kids could play with.

Later that week we found two closeby swimming pools that are awesome: not too many tourists, a nice bar/friendly people and not too expensive. Sadly those swimming pools are closing up at the beginning of September.

Robbert and Lucie wanted to learn how to dive. I tried to explain them my own way but that came with a lot of frustration hitting the water time after time. Youtube to the rescue.

After watching the video in the swimming pool bar the kids were eager to get this over within 6 minutes. Turned out it wasn't as straightforward as advertised where the biggest challenge was getting over the fear of going head-first.

Within 30 minutes Robbert had evolved to diving standing up while both Marcel and Lucie were trying to catch up. I think if we practice for a few more days they'll all get it :-)

Fire-wood 🔥

As we took out two floors from the old house we had so many old wood beams that were previously supporting the floor. It was time to take out the chainsaw and turn them into firewood for the next winter.

Enjoy the timelapse.

Notice how the chickens are not afraid of a running chainsaw and are fighting to eat the first worms/insects when picking up the last beams of wood.

Last Thursday the day had come to pack up our stuff and take the 1250km drive to our new home.

A new car

Because the village is impossible to access with a normal car (max width 180cm) and there was a lot work in the house (getting rid of stuff left by the previous owner, building new floors, ...) I ended up buying a new car in Belgium.

The requirements for the car were for it to fit and be able to tow heavy loads (+1500kg) and 4x4 drive. Bonus points for a car with scratches as I knew it was going to take a beating with the planned usage.

After quite some digging I discovered that there was an SX (small trim) version of the Fiat Fullback that met all criteria. Did you know there are sites to compare the dimensions of different cars?

Now I know what I wanted I needed to find a 2nd hand Fiat Fullback for sale. Because I needed this specific trim (SX) I had to look hard and discovered that throughout Europe there are only about 10 of those cars available on the major 2nd hand car websites.

I got lucky with a black version being readily available and went for a visit and bought the car on the spot. The only downside: no automatically foldable mirrors which I figured I could fix using after-market components.

The Move

As we now had 2 cars it was easier to plan the final move. We had to move 3 of our children and 7 chickens. Preferably alive.

I spent all Wednesday loading the cars. Figured that chances for the chickens to survive would be higher inside the car 😱 . My brother and I constructed a compartment on the backseat of the Pickup.

After about 800km, which went very smooth, we decided to spend the night in a hotel. We needed to find a place with a garden so we could de-stress the chickens. Talked to the owner and agreed to give them some room at the back of the hotel with the portable fence I took with us.

The night in the hotel turned out to be terrible. Both Annelies and I only slept for a few hours as it was crazy hot (somewhere around Limoges) and our room did not have AC and the window was situated next to a busy road. ​ 😴 The only good news is that I was fully caffeinated and ready to go at around 6:30.

On Friday we had the most beautiful part of the trip in front of us passing through the Pyrenees to end up on the Spanish side.

We arrived in the Village around 14:00 where I was getting increasingly nervous about the final 300 meters. Will it fit?

As I was loaded with so much stuff I was destined to drive the car to the front of the house. Some of the villagers discouraged me as they thought the car would not fit but it did. Just one minor scratch :-)

The first days - Basics

The plan for the first days was to make sure the basics work (warm water, electricity), clean the house, make sure the children have a nice room and create the space able to unpack all of the boxes.

Because no one has lived in the house for almost 7 years it needed a deep clean which took much longer than we anticipated. My Mom decided that she wanted to come by and help us out during her Holiday. This helped a lot and allowed me and Annelies to spend time on other essentials.

After a trip to Ikea (a 3-hour drive to Barcelona) and using some of the things we brought from Belgium (beds, bedframes) we managed to give the children a room they are all quite happy with.

The rest of the time was spent cleaning up the garden, taking out trash left by the previous owner and removing old/outdated cabling and satellites or antennas mounted on the outside of the home.

A timelapse of cleaning up the garden:

Additionally, we made sure to create enough time to enjoy the surroundings. With the kids we took the SUP to the lake three times, enjoyed a Wim Hof-style cold bath under the village waterfall (11 degrees) and spent some time around local restaurants. ❤️

The good and bad

As everything still feels like a holiday it's too early to draw any conclusions. There has been quite a bit of emotions around the idea that this is permanent. For now, I was able to turn around the mood by doing something fun.

Although the temperature is around 35 degrees it doesn't feel that hot. There is a constant breeze and the cold lake in front of the house acts like a huge airconditioner. It cools down quite a lot at night and there are not that many mosquitos. A lot of flies though!

Anyway, too early to evaluate. What I can say is that life slows down a lot here. As I'm writing this the kids are playing in the lake in front of the house and everything is so quiet. Everyone you talk to in the village looks like they have all the time in the world and are genuinely interested in understanding how we're experiencing the move.

That's it for this update. Another one next Friday?

Two steps forward, one step back

This would be my most accurate one-liner of what it feels like to build a company from a three-person founding team to a few-million revenue/30+ headcount business.

And the same is true for the product team where we've evolved from early years of rapid experimentation ("let's try agile", "adopt Jira company-wide", "idea + execution on the same day") to a more stable and well-functioning product development pace which has been paying off.

Break up into three teams

In the last 12 months, we've broken down the product team into three autonomous teams with their own projects and tasks. This meant we had to hire at least four more people for the product team. We still have some open roles.

So now every team has a dedicated product designer and a mix of frontend and backend developers.

Fun fact: our team uses Elvis Presleys song titles: Mystery Train, Tutti Frutti and Hot Dog.

Breaking up those teams was a logical decision to further scale the product team. Many business books mention the 'autonomous teams' approach which certainly feels like the right way forward.

The outcome of this change is that team members work together more closely and are better focused on the projects assigned to their respective teams.

We've also carried through that team split in Linear, where every team has its own space, projects and stories (that have a different prefix). This change has resulted in more collaboration (within teams) and a more predictable pace. Two steps forward!

One step back

But there are some downsides to this approach:

• Everyone stays in the same team. This impacts the overall social dynamics and reduces the amount of information sharing.
• More work to assign and plan issues. Because bugs now belong to a team there is more work in triaging/allocating the right person as one needs to think about which team is responsible for that part of the product.
• Harder to deal with holidays. If a person in a 4-5 person team takes a holiday you lose 25% productivity. That planning is almost impossible if that person is the designer or the only backend developer in that team.

Company challenges

And reflecting a bit more on the recurring problems we've been experiencing as a company I keep coming back to three main areas:

1. Doing too many things simultaneously: Both Jesse and I have a hands-on approach which I believe gets us to start too many things with no clear end in sight.
2. Being founder driven: You must have heard this quote 'going from 0 to 1 million ARR is a lot easier than going from 1 to 5 million. That is because you can get to the first million with a few talented individuals (and you don't need management skills).
3. Working/Overspending on stuff that's not that important: I have many projects that I am 100% sure took us way more time, energy, and resources than we’d ever wanted to spend upfront. Heck, we should have probably never even tried if we knew it would take that long.

And 1. and 3. can kill motivation as team members feel like projects are going on and on with no end in sight.

The company we want to be

We're big believers in "the calm company" approach where teams are given enough freedom and responsibility to plan their own work. In this flat structure, work is organised by the people rather than a top-down command-and-control leadership style.

But while it's easy to hand out copies of 'It does not have to be crazy at work' it's much harder to implement. I have discovered that this is a long-term transformation that touches many aspects of the business: hiring, mission/vision, and most importantly an internal transformation going from management to leadership which are two entirely different things.

Product team reorganisation

I'm not the biggest fan of being too strict about applying so-called "proven methodology". We use a set of concepts from different methodologies where we cherry-pick and adopt the stuff that works for us.

Still, I was pondering how to improve the way we work together and ship stuff within Prezly and I found inspiration in two books/concepts:

Shape-Up (by Basecamp)

Shape-up is a project/product management method by Basecamp with good principles and guidelines on how to work together as a product team.

As software teams start to grow, some common struggles appear:
​​
​- Team members feel like projects go on and on, with no end in sight.
​- Product managers can’t find time to think strategically about the product.
​- Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”
​​
​From Basecamp book Chapter 1: Growing Pains

This spoke to me a lot. In fact, it's a better-written version of some of the challenges I highlighted in the company challenges part. And there are three things I think we should implement within Prezly:

1) Strong focus on scoping (shaping)

Everyone who wants to suggest a change/improvement needs to spend time on shaping/defining the problem well.

In practice, it is mostly senior people or me/Jesse that start shaping ideas. But having an explicit process (shapings documents, betting table) enables us to think about the problem enough and let the team work on the solution (within certain constraints).

2) Circuit Breaker / Appetite

The idea is that every project comes with a certain appetite which reflects how much time/money/resources you want to spend on a problem. Teams get a fixed amount of time to work on an issue; after that, the 'circuit breaker' mechanism kicks in, forcing the team to stop working.

This concept is extremely empowering for the people pitching and shaping the idea.

3) The Betting Process

When first reading the Shape-Up book, I internalised the betting process as some kind of democratic/point-based voting system where the pitch with the most points wins.

But it's nothing like that.

The betting process is more like a conversation that keeps many different aspects of the business into account:

• Who would be the right person to work on this?
• Is that person free right now? Do they have a holiday planned?
• How well does this project align with current business objectives?

These are simple questions to answer individually, but together they create some kind of puzzle that is hard to explain.

In the video, Ryan mentions that the betting process probably deserves its own book which I think is much harder to write as I it's more of an art than a technique.

In the first betting session, I noticed that the conversation creates alignment between leadership. The conversation is not about who is right (because no one knows) but about which experiment we're doing first and how much we want to spend.

Reduce team distractions

You want to avoid any distractions for a team that is allocated to a shaped project. This is critically important as a team accepts the challenge of solving a specific business problem within the provided timeframe (appetite). ​
​​
​But, if you're going to distract that team by assigning P1 issues or allocating them to client todos there is a big chance the whole shape-up method will fail. But then again, some things can't wait.

Quick Reaction Force (QRF Model)

A while back I read a great medium article about creating a dedicated team for interruptions which they call the QRF (Quick Reaction Force).

Engineering Org Structures— The QRF Team Model

This model will work well with our Shape-Up experiment as it will ensure we have an available team for interruptions.

The truth is, some things can’t wait. Compliance demands, a new employee onboarding, a large customer’s tiny configuration change — these are activity-generated work that just needs to get done with some sort of time-sensitive cadence.
​​
​From Medium.com - The QRF Team Model

The model that works

By combining the Shape-Up method and the QRF Team Model the structure of the product team will look a bit like this:

I'm confident this combination will address some of the issues raised by the team during the last retrospectives. Additionally, the QRF model might create room to work on essential tasks (refactoring, admin tools) that currently do not get enough attention and might never be planned/shaped.

At the end of each cycle, we form new project teams and move people around based on availability/expertise. I believe this rotation might positively impact team culture and knowledge sharing, but that's all to be confirmed.

I will post back in a few months with better insights.
​​
​Inspiration/Good reads:

• Shape-Up (by Basecamp)
• The QRF Model by Joseph Gefroh
• Linear.App - Method
• Why Squads are a Popular Failure for product teams by Spotify

Upgraded the blog. It's like Bea and Tailwind had a baby

In the previous blogging theme I hacked away in a few evenings I was lacking quite some functionality like search and paging. Also, the theme didn't score great in SEO and accessibility lighthouse audits.

In the last weeks, the team has been helping me rework the blog using our existing/battle-tested tools and packages.

Previous Blog

When I first moved my blog to Prezly I started from an empty NextJs project. Using the PrezlySDK and ChakraUI I was able to set up a blog with minimal effort.

But it had some issues and a list of todos that were already solved in other Prezly themes.

The new lifelog.be

This blog is still a Next.js application that is pulling in content from the Prezly CMS. But instead of starting from scratch, it's forked from the Prezly Bea theme which comes with everything I need to power this small blog.

The site is deployed on Vercel (the company behind Next). The developer experience is awesome where it auto deploys the blog on every commit/merge to main.

The site is rebuilt (Server Side Generation) and auto-deployed every time someone commits to main or when I write or update some content in Prezly.

But because the codebase is a fork from the Bea theme it's making us of different tools/packages that make my life so much easier:

• prezly/sdk: interaction with Prezly APIs. Entity type definitions
• prezly/content-renderer-react-js: story rendering that supports images, galleries, videos, embeds, tables, contact cards, etc....This package turns Prezly story format into React component(s)
• prezly/analytics-nextjs: tracking snippet to feed interaction (page visits, email campaigns, ...) into Prezly while giving the visitor privacy controls.
• prezly/theme-kit-nextjs: a collection of data-fetching functions, hooks and utility functions to reduce number of boilerplate/repetition code in different themes
• prezly/themes-intl-messages: translated strings to enable theme translations
• algolia: search functionality within the Prezly themes
• next-plausible: enable plausible analytics on the blog

Upcoming/Todos

With this update, there are a lot of things that were addressed in the default Prezly theme. So my previous todo/issue list now looks like this:

• ✅ Use theme-starter boilerplate code to fetch content
• ✅ Score better on Lighthouse Audit tools
• ✅ Allow paging from home page
• ✅ Support Search
• ✅ Implement subscribe functionality (stay updated)
• ✅ Improve SEO/meta tags
• Add RSS feed (and any other feed protocols people use)
• ✅ Get rid of ChakraUI
• Make better use of Uploadcare.com (using uploadcare-image)
• ✅ Bring back sitemap.xml
• Fetch intro text from newsroom boilerplate (make customiseable)

We bought a house in Catalonia and we're moving this summer

We've been contemplating a move abroad for a few years now and we finally did it. In August 2022 we'll be moving to the Spanish Pyrenees where we bought a house.

But, why?

I've been trying to answer this question for hundreds of times now and I've learned that the best answer is

Why not?

It switches the conversation from a defensive (why would you be so crazy to do this?) mindset to a more balanced conversation where people try to convince me that Belgium isn't that bad. And it's not.

The truth is that we don't really know how good it is to live and work in Belgium because we never compared. Every time we take a long holiday we realise how small our part of the world really is and dream about how things would be somewhere else.

Additionally I would like to be closer to nature and my kids to spend more time outside.

The House

The house is an old 2 story building in the center of a small mountain village. While the house has 7 bedrooms it doesn't feel spacious. That's because it's two different houses merged together which results in different floor levels and a lot of small rooms. We're looking to fix that over time.

The house is located in a mountain town (Pyrenees) at an altitude of 900m. The village ​ has about 30 permanent residents so we are increasing the population by 15%.

The Plan & Moving

We figured the summer is the best time to move. This gives us enough time to prepare before the kids go back to school (in Catalan) in September.

We don't want to take too much stuff so we're going to move our belongings in two batches using the MobileHome and car+trailer. I also promised the kids I could bring the chickens which I'm starting to regret.

Will try to update this blog with our adventure. Onwards!

Disclaimer: I am no expert in product analytics and definitely not claiming to be. I did spend the last 5 years playing with a lot of different analytical tools and made a lot of mistakes. With this post I hope other people can avoid some of those.

While most startup books and marketing series talk about being 'data driven', I've come to understand that it's easier said than done. ​
​​
​I've done my fair share of product analytics and I have found myself trying to convince people that the only way the project could be successful if we would measure and evaluate it. But that isn't always that simple.

In the last 10 years, I've built my own tracking stack, became a segment.com product expert and have used over 30 integrations from the segment.com catalog.

Here are some things I learned to get better at (product) analytics:

• Define what you want to report on
• Use a tracking standard
• Pick good event names
• Don't use event names if you can use event traits
• Do not count on page() calls
• Choose tools that support group()
• Mix server and client side calls
• Document your tracking schema
• Teach your team analytics
• Integrate tracking in your stack

Let me know if you have any other important tips I can learn from.

Define what you want to report on

This is the mistake I made the most:

Look at all these cool/powerful reports we can make

Before you think about tracking or product analytics, try to define the thing you want to measure as simple as possible. KISS. I recommend to formulate it in a question format:

• Bad: How much better is our new account activation wizard?
• Good: How long does it take on average to go from step 1 to step 5 of the account activation wizard?

• Bad: Can you create a dashboard of the features each customer uses?
• Good: How many of our active customers (non-trial) have used feature X at least once in the last month?
  ​

Defining the question up front (one of the key concepts of Metabase) works well to keep it simple.

Use a tracking standard (analytics.js)

When we started out we had different integration code for Mixpanel, Customer.io and other platforms we wanted to send data to. Which meant that we had to maintain those tracking calls separately.

Note that the more integrations you use (we currently use 6) the more code you need to maintain. Abstracting this all in one tracking language/standard was the main reason for switching to segment (using analytics.js) at that time.

The analytics library (available in open-source) will translate that payload into the format your integrations require.

Pick good event names

Install a consistent naming scheme for your events. We stick with the following rules:

• Human Readable
• Split words by spaces
• [Entity] [Action]

Which leads to events like:

• Recipient Added
• Story Published
• Story Removed
• Contact Tag Applied

Don't use event names if you can use event traits

Regardless of which integrations you have enabled there is always a limit on the number of events you can use. Intercom has a default limit of 120 events so at some point you're going to hit limits.

That's why you'll find yourself balancing when to use a dedicated event vs adding more context in the tracking payload.

An example:

But that decision also depends on which integrations you have enabled. While Intercom only allows setting up automation based on the event name, other tools like Customer.io are much more powerful.

Mixpanel allows you to use that tracking payload to create Custom Events.

Don't count on page() calls

Most tracking libraries (as well as analytics.js) will start tracking data right away based on page paths or routing changes (SPA libs). That means that you immediately have interesting data to use.

I learned that this data is oftentimes not that trustworthy or useful:

• Route changes (changing urls) mess up historic reports
• Often lacks context (tracking properties)
• Variations of content (non-canonical pages) need extra thought

That's why today we're not tracking or using any page() calls in the app anymore but rather use our own events.

Choose tools that support group()

Most SaaS businesses have the concept of one account that is linked multiple user accounts. When we started using product analytics all events and tracking properties could only be linked to the user entity and thus also every report was tied to a user.

To work around this we found ourselves adding grouping tracking properties to the user analytics payload:

These properties allowed us then to create reports for all trials` or grouping certain reports by company...

Introducing group()

There is a better way to do it and that's using group() calls which is much more inline with most SaaS businesses` user/grouping model.

This way we're splitting up user and company properties in their own calls:

• Identify() properties → Traits/properties that belong to a user
• Group() properties → Tying the user to a group + traits/properties that belong to a company

These group() calls were first introduced in 2013 and while most integrations have caught up make sure to double check that your integration supports group() calls. It makes product analytics so much easier!

Mix server and client side calls

You can't fully count on client side tracking calls for important reports. That is because:

1. Users might have ad blocking browser/extensions
2. Something might go wrong with the tracking call (CORS, network issue, JS error...)

That's why we're using a mix of server side and client side calls. Important calls like 'Trial Account Activated' are triggered both on the server and the client to make sure that any automations also trigger for people that don't want tracking.

Document your tracking schema

I have yet to see a company with a clean tracking plan. As time goes by people add tracking properties, rename certain traits or create events that are not named properly. What about 'test' events?

That's why I'd suggest creating some kind of tracking document (Mixpanel has the tracking lexicon, segment has tracking plans and protocols) to keep track of your events and user/company traits.

Bonus points for keeping some kind of status to deprecate/clean up old events and getting everyone to use this!

Teach your team analytics

For any business to embrace data driven decision-making, your team needs to understand what's going on and be able to make better calls using data.

Here are some things I do to encourage people to use data:

• Create a document explaining analytics at your company
  • Include the tools (mixpanel, amplitude) they can use
  • Highlight which data is where
  • Link to the tracking schema
• Give everyone full access to segment/analytics tools
• Set up dashboards/reports for your team and teach them how to use it
• Ask for success criteria when defining/starting projects
• Argue using Data. Participate in conversations linking to a report/chart/data to back you up.

Even if you do all of the above, it's not a guarantee that people in the company will take data as serious as you want them to.

Integrate tracking in your stack

While most analytics platforms require you to load their javascript/sdk on your page I ​ strongly recommend making the tracking components part of your build pipeline. This will bundle all analytics interactions as part of the main application and will be much more reliable. Analytics v2 has an npm package you can import in your project.

In combination with that, you can proxy your analytics calls. This will turn third-party tracking calls (to external domains) to a first-party XHR call similar to how most applications interact with their API making it practically impossible to block by browsers or blocking extensions.

Because we're doing an extensive feature audit I am going to write more about the different ways we use product analytics to make roadmap decisions. In absence of a subscribe box you can follow-me on twitter for updates.

Preview image by Isaac Smith on Unsplash

The interface in which I am writing this blog post is over 5 years old and has UX issues. A quick write-up of what we're thinking about and what we are struggling with.

This project can be broken up in three different components:

1. The writing experience / Editor itself
2. CMS / The story editing interface
3. The publication flow

The editing experience

Turns out that building a good editor in 2022 is not as easy as it sounds. While Google Docs, Dropbox Paper, Notion and Coda have their own proprietary solutions there is nothing out there that comes close to that level of quality.

In our research, when it comes to open-source projects, there is only really SlateJs (24k stars) and TipTap (14k stars) worth considering to build an experience on.

Gijs Nelissen on Twitter

I've wrote about this in a previous blog post:

Create an editing experience people love

We've been investing in our version of slate editor and we've come a long way including keyboard shortcuts, a new + menu, embeds/website bookmark, auto-formatting/detection and improved text-alignment.

We still have long way to go but a solid plan how to get there. Short/mid term improvements include:

• better linking (link to internal references)
• improve the support for pasting from GDocs, PDF, ...
• placeholder components
• drag-dropping components
• more customisation on sizing/alignment of galleries

Most best practices can be borrowed from popular editors like Coda, Google Docs, Notion and even Microsoft Word. Oh, did you know the most requested editor feature is text-justification (for the web)! 🤯

CMS / The story editing interface

Turns out that this is a much harder problem to solve. Here is an overview of the story editing interface for a multilingual story with 2 translations in an account that has multiple newsrooms.

Although we do not have any major complaints (it's been in use for over 5 years) and is being used 1000x per day with over 300k stories published I feel there is a lot of room for improvement.

Some of the issues we might want to address:

• The left sidebar draws a lot of attention taking away attention from the content
• Language settings everywhere. The sidebar has a language switcher while translations and switching translations happens in the 'manage' dropdown
• Publication settings like visibility and publication date are in the left sidebar but the flow to finally publish a story is in the right top corner
• Newsroom picker is a setting but was lifted as some kind of super setting. On other pages it acts as a filter/navigation but on this page it's a setting
• General page canvas. The combination of the sidebar, sub-navigation and manage tab makes the interface overwhelming

The publication flow

In today's interface the publication flow is mixed in with the rest of the settings and the writing interface. And because some of the settings (scheduling, embargo, private story) affect the publishing behaviour this comes with some confusion.

To work around this we have introduced a 'great job publishing' success modal together with dynamic labels on the main publish button.

The more we work on the story edit and gather more information through desk research and customer interviews the more we are realizing that it might be better to break up the publication flow all together.

We're stuck

At this point I feel we're stuck. We've looked at all our competitors, the best CMS systems out there and have browsed the web for inspiration.

It feels like we've dug our hole too deep and are trying to solve too many things at the same time. Please send help!

Here is a list of assets/attempts (please note that these are just random picks from a larger project including low fidelity wireframes or idea sketches)

I've been thinking for a while that I needed to document the different ways we use Prezly to run Prezly. Browsing twitter today I saw Peter Suhm started a great trend.

Peter Suhm on Twitter

So figured it was time for me to do the same. Let's go!

#1 We send our customer newsletters through Prezly

Every month we send out a wrap-up of what's going on with Prezly. The entire content of the newsletter is added to the body of the email while they are published in the help section.

The goal of this monthly newsletter is to let our customers and prospects know what we've been working on together with some quick tips and pointers on where they read more.

Throughout the website, there are a number of subscription forms, together with the trial sign-up those email addresses are going to our accounts contact database and labelled with the 'newsletter' tag.

#2 The changelog is powered by Prezly

Within Prezly we have a dedicated 'changes' newsroom that is updated every time we change something worthwhile in the product. That content is then going to 3 places:

• Our website /changelog
• Within the app on /changelog (different UI, see screenshot)
• Reminder (small icon) there is something to read in the notification centre

As we continuously change the app and make minor changes it's important our staff and customers are informed about what's new.

Note: this page is mainly accessed by power users that spend significant time in the app. Similar to how I'm personally reading everything the @linear team posts in their changelog.

#3 Most parts of the website are powered by Prezly

One of the goals was 'drink our own champagne' (a better version of eat our own dog food). This is because it's the only way we encourage Prezlians to use our own content editing tools (the editor).

How we did this might become a little technical so feel free to skip this part:

The website is nextjs powered by Contentful headless CMS. This allows us to build complex pages composed of different components and UI elements. Not something we do at Prezly.

But we did want some content-heavy pages (/academy, /news, and /help) to be written/maintained from Prezly. That's why we came up with a hybrid approach where we have 3 newsrooms in Prezly:

• /academy → www.prezly.com/academy
• /help → www.prezly.com/help
• /news → www.prezly.com/news

These newsrooms hold all the content the make up this website and are pushed to contentful in their own content type (PrezlyStory and PrezlyCategory) on every update. Using the PrezlyContentRendererReact we then turn these articles into beautiful pages like this example.

The advantage of this approach is that everyone in Prezly (customer success, marketing, product people, ...) needs to work with the Prezly editor/CMS at least a few times per week.

Additionally, we can use Prezly articles in newsletters, sales follow-up and pitches as they are all sent from Prezly too (see #4)

#4 Sales follow-up and outreach

We try to make sure that all stakeholders (Prezlians, family/friends, alumni, customers, prospects, partners) are all organised within the Prezly CRM.

This allows us to send updates all from the same platform. Because most of the content is already in Prezly (see #3) it's super easy to build the content we need.

Some examples:

• after a sales demo, a customer asks to follow up with some specific articles about the product
• preparing a customer review we notice they are using feature X or Y wrong

Here is a quick recording of what that flow looks like with everything being in the same system:

#5 Internal Communication - Heartbeat

For any major team announcements, we use what we call 'heartbeat'. It's a secured newsroom (need to sign in with Google Auth) that has a timeline (the heartbeat) of everything that is important to know.

Oftentimes we also set up an email campaign notifying people of that update and copy-paste the URL in Slack.

A nice addition we added to heartbeat is a way to comment/start a conversation (in discourse) around every post. That conversation is then embedded below the heartbeat story and available on discourse (slow/thoughtful conversation).

#5 This blog

This blog is powered by our own product. Although the frontend (NextJs, Vercel hosting) is entirely disconnected from the the CMS it is being used as a headless CMS.

I've written about how I build this blog before. (Switched to a new theme later).

Those are the main ways we use Prezly at Prezly. As Peter mentioned, it would be great if other product people wrote a similar post about their own products. I'll make sure to keep a list here:

• How Reform uses Reform
• How Prezly uses Prezly
• How DebugBear uses DebugBear to run DebugBear
• How ZipMessage Uses ZipMessage to run ZipMessage
• How Eduflow uses Eduflow to run Eduflow

Thanks for reading along! 🙏 And kudos to Peter for the great initiative!

This holiday we spent a month with the family in Sweden 🇸🇪. It was awesome. This is a quick write-up of note-worthy tips, the route of our trip and the experience travelling with a family of 5.

Camper/Mobile Home

We were in a big mobile home (7.5 meters) that has a sleeping capacity of 6. With everyone sleeping inside it tends to get really crowded and it takes a while to transform the living area into the sleeping area. ​
​​
​The biggest disadvantage of sleeping inside is that the living room can not be used as soon as the kids go to bed (between 8 and 9). Considering that in some areas there are a lot of mosquitos once the sun goes down we figured we'd bring two 10-second tents to have 4 more sleeping places outside.

Other stuff I took to make the trip more noteworthy:

• Inflate-able canoe
• Sup board
• Four bikes
• Table + Chairs
• Skateboard (son)
• Step (daughter)
• Too many pumps

The trip

We started the trip in Trelleborg and did a tour from the South to the East coast of Sweden all the way up to Stockholm (which is only about 1/3th of the country). Sweden is Huge!

Week 1 - South Coast

We arrived on the ferry (from Rostock Germany) in Trelleborg. Since it was late, 22:30 when we got through border control, we drove to the closest camping which in hindsight was the most commercial and expensive camping we did in the entire holiday.

On the map, it looked great (South West corner of Sweden) but it was pretty much a full campsite with over 100 campers nicely parked between 4 lines. Icecreams and mini-golf at the reception 😱

In the morning I could not wait to get out of there and discover 'real' Sweden. Based on weather forecasts we decided to do the East coast and drive our way up to Stockholm.

Leaving the camping site our first stop Falsterbo beach. On our way there we passed Mikes pizza restaurant with a huge 'Pizza World Champion' banner which did it for the kids. Bribed the kids with some variation of

We'll go to the pizza place after you all play on the beach/in the water to make sure you're all hungry enough

It worked 🍕

It was later afternoon when we left the Pizza place with destination Ystad. The sun was out a curly road that was right next to the ocean and trees/forest on the other side. A few km's later our kids saw someone diving from a small jetty and asked me to pull over.

On the parking, we met a super nice German couple who were wrapping up their 3 week holiday and decided to stay.

It was a super nice spot next to a small sand beach! The road was close (30 meters) but it didn't bother us that much. First chance to take out the SUP-board and Canoo so decided to go all the way 💪🏻. Kids wanted to sleep in the tent, and after they were all down we spent a super nice evening with the neighbour couple that was travelling with a 6-month baby.

After saying goodbye we were on our way to Ystad where we took off the bikes for a short tour and our first chance to do a Swedish Fika (tea/pastry) after which we took a long drive. With the evening approaching most of the spots on Park4night were taken and we had to keep driving to end up in Gislövhammar where there was a small green campsite with a great view over the sea.

The kids made friends, we met a lovely Belgian couple and their dog and decided to stay another day. The second day we went for a Belgian BBQ and invited another Dutch couple to join us (to finish the wine).

In the 2 days on this campsite we also did:

• A 12km run with Michel (fellow Belgian) who was training for a marathon
• Visited Ales Stenar
• First Swedish supermarket (no masks 😃)
• Played our first game of 'Set' which we ended up buying a week later in Stockholm

The next day we stayed in a small harbour in Hörviks Hamn. When we arrived all the paying/good spots were taken but I managed to find a spot that was not intended for camping. The spot turned out to be great. It was 5 meters from a small beach.

In the harbour, there was this small restaurant where we had our first restaurant visit so far. It was great (although the restaurant was understaffed and everything took so long). The kids were playing near the docks, we had the best riesling, the good was great and we could watch the sunset from our table. ♥️

The next morning I took Annelies on the SUP-board before we resumed the journey. Next stop: Karlskrona (or somewhere close).

I got a tip from the German couple (day 2) that the islands near Carlkrona are super calm and worth a visit.

On our way to the bookmarked spot, we passed some small camping sites one of which was Kustgården Senoren which turned out to be an awesome camping site. Only 4-5 campers, a small private beach, trees all the way to the coastline and evening sun. That's our spot!

We stayed there for 3 days. The kids were enjoying themselves swimming to the island on the other side or spending time on the playing ground. On the 2nd day, we spent time in Karlskrona. I took off the bikes and we biked across the city visiting the submarine museum, the marina and the park. Beautiful day!

Week 2 - East Coast + Öland and Stockholm

We initially wanted to visit Gotland but the ferries were all booked. Some of the people we met warned us that Öland is super touristic and some of them were advising us to skip it. As it was raining that day and we wanted to drive over the bridge we decided to give it a go driving all the way up to the North of Oland.

I didn't like the harbour that much as there were too many campers, it was very windy and pretty much concrete everywhere you could see. Had some time to dry some of our laundry (the previous place had a washing machine) but didn't trust the kids to just hang in the harbour because of the wind and the water.

We found a great restaurant in the harbour and enjoyed some seafood where I encouraged the kids to all try an Oyster (which they did. Didn't like it).

After the kids went to sleep I met a group of travelling swedes that invited me to have a few drinks. I brought Belgian beers. Stayed there until about 2 in the morning where they convinced me to try a few of their typical Swedish drinks: Rum/Coke, Sprite/Rum and Whiskey 🤕

The next day was rainy and we decided to drive to Vimmersby to visit the Astrid Lindgren (wikipedia) museum. The inside of the museum was not that impressive (I get bored really fast) but the gardens were great!

I wanted to find a super isolated spot and try 'real' free camping (preferably next to a lake). We drove around for a bit and were looking at google maps to find a small road that led to the water. Took about 45 minutes to find a great spot with no one around.

Stayed there for 1 night only and drove up to a super nice farm in Ydre. We were welcomed by a couple that, together with their 3 kids, moved to Sweden 1 year ago to start a small farm. There were able to buy a piece of land for in his words 'less than a new Volkswagen transporter' 🤩

Every night (stayed for 2 nights) we sat around the campfire and met other guests staying there or had some time to get to know the hosts and their stories. Awesome memories, hope I can be there someday and see what they did with the farm.

In the morning it was pouring rain which made the host happy as it hadn't really rained in about 3 months. Joked about Belgians taking the bad weather with us and left for Stockholm.

Because of the weather forecast, we decided to book a short stay somewhere close to Stockholm to visit the city. We found a great spot on Airbnb next to a river with our own private jetty. The house had a separate lake house with 2 extra beds, a Sauna (which turned out was not working) and a great kitchen. A nice feeling after spending 10 days in a 2x6 camper van 😀

Enjoyed spending some time in Stockholm and were able to meet Frederik's family (and baby). My kids were so happy to see Frederik again (we worked together quite intensively a few years ago starting Prezly). We made some great memories!

The day after we spent a day in the city Center of Stockholm, gave the mobile home a good clean and started planning the rest of the trip as it was time to see the rest of Sweden.

Week 3 - The lakes

We wanted to spend more time around the big lakes and drove to Västerås (pronounced Westeros like GoT).

We found a nice spot on an almost empty grass field next to a bar/restaurant which was built over a small river. There was a mini-golf terrain, almost no tourists and a nice pizza place which made us stay for a day longer.

The kids wanted to swim and I promised them to do a big tour on the river with the sup board. Inflating the board is a real workout as it needs 1.5 bar to work well but it was totally worth it! We spent a few hours on the water making sure the kids were tired enough for a smooth bed routine 😴

The next day we drove to Örebro to visit the Stadspark which was advertised as one of the most beautiful parks in Sweden. While the kids were playing in the playing ground had some time to walk through the park and found this beautiful walnut tree.

After the kids were tired of the playing ground I told them they'd get ice cream if they could guess which tree in the park is on my top-5 of the most beautiful trees I've ever seen. They guessed it quite easily 🍦

We left the city park and drove all the way up to Värern which is the biggest lake in Sweden and one of the largest lakes in Europe. It's beautiful.

Found a camping spot right on the east side of the lake. Sun was out, no clouds at all so time to set everything up and take a swim. The water was super clean and we stayed in much longer than planned. After dinner, I told the kids to go and find some wood to make a campfire. We had bought marshmallows a little earlier and allowed the kids to get sugared up right before they went to sleep 😫

Annelies wanted to go more North to see real Sweden so we left early the next day driving ​ North and closer to the border of Norway. Most of the campsites were full and there were noticeable fewer spots on park4night. We landed in Årjängs Hembygdsgård, a small camping site next to a lake.

The best thing about this spot was a nearby coffee bar/restaurant/hotel that had an awesome backside terrace with a view over the lake. We went in for a quick coffee and spent almost 3 hours. We started talking to the staff, met a fellow Belgian couple while the kids were playing inside. The place was so awesome that we had to get a table for dinner the same evening. One of the best meals/experiences we have had in Sweden so far! Even with the limited menu choice (we did not have a choice) the food was great, the staff super helpful and the view was stunning.

We wanted to get back to the lakes so drove all the way down to Upperud where we found a horse farm that rented out Canoes. Because it was raining all evening we went to bed early and kept everyone inside (no tents). In the morning we prepared lunch, double-coated the kids with sunscreen and put on the lifejackets. Canoe trip!

This turned out to be awesome! From the farm, we had to follow a small creek for about 1 kilometre to get to a side lake of Värern. Choices for Canoes were limited so we got two single Canoes and a double one. I took Marcel and Lucie in the double one where our youngest sat on my lap. This was quite a workout and outside of the kids complaining (I'm tired! I'm hungry! My arms!) it was by far the most exciting thing we did so far.

We spent about 4 hours on the water and got back to the camper about 30 minutes before a big thunderstorm. Packed up the tents and decided to drive through the bad weather on our way to the bottom of the lakes. We arrived in Kedumstorp later that evening. Everyone was tired after the boat ride and road trip so we took out a pizza and stayed over in what in retrospect was the worst spot of the holiday (which was still a 6/10). We left at 9:30 to drive to Hjo.

In Hjo I did not want to camp in the commercial campsites or harbour so looked for a spot close by so we could visit the city by bike. Found an awesome spot close to a small lake west of Hjo.

Outside of the flies (there was a public toilet that desperately needed taking care off), it was a great spot!

We ended up staying for 2 days with mini bike trips to Hjo city centre where we had the best ice cream. The sunsets on this spot were awesome and the water was only 50cm deep for the first part of the lake. This allowed the kids to play in the water until it was time to sleep or food.

Because the water in the lake was a little smelly we needed to wash ourselves every time we came out. We figured out we could do outside showers opening the camper side window and pulling out the showerhead.

Week 4 - West Coast

All the books about Sweden talked about the west coast being so beautiful. The Swedish people we met during the holiday told us that it's the side of Sweden the Norwegians took over

They like to come over with their big boats, expensive cards and you know, they just take over...

So we had mixed feelings about exploring the west coast. We drove up all the way to the Norwegian border where we stayed on a small farm (with 2 horses). Upon arrival, we were hesitant to stay the night but the owner convinced us

Yesterday a moose came down that hill and were grazing the field here. The German couple that stayed here saw it around 6 in the morning. We also have the white moose here.

When we left for Sweden we said it would be great to see a wild moose and now we had the opportunity to do so. We set up the camper and tents and called it a night early. I had set my alarm clock to get up around 5 in the morning to start spotting. Nothing :-(

As we were close to the Norwegian border we decided to drive up there to see the Älgafallet waterfall and the old border bridge (the old Svinesund Bridge). After that, we drove up to Strömstad where we had some time to go swimming and found a nice small tapas restaurant. The perfect day ❤️

I did tell Robbert about my morning activity and the white moose and he wanted to double down.

Dad, if you wake me up I will do the deer watch with you. Maybe Mom can help too...

To maximise our chances we started to search for tips 🤓such as at what time of the day are Moose most active? Do they come in groups or by themselves? I decided to talk to the owner once more to get some more pointers.

Although I was tired of last time, and not too confident we'd have a chance spotting some we agreed to a new schedule for the next morning.

• Gijs: I took 3:30 -> 5:00
• Robbert: 5:00 -> 6:00
• Annelies: 6:00 -> 7:00

Crickets 🦗🦗🦗...We were all pretty disappointed not spotting anything significant (2 Crain birds and a small deer) we figured it was time to move on and also prepare the way back to Belgium (ferry vs bridge, driving at night or not...).

I found a great sheep farm in Ostroo that had some room to park up to 8 campers. As it was a beautiful day we drove down and decided not to visit Goteburg. I don't know what it was but after our Stockholm visit, we didn't feel like getting back to a city.

Right about when we arrived and set up the tents it started raining while the sun was shining so we had to go hide inside.

We put the kids to bed on time (a long day) and I found a small window to take a short run. I got lost and didn't want to take my phone so the run took way longer than expected. I think I ran around 15km and arrived around 11:00 where everything was pitch dark.

Annelies and I thought it was a good moment to start preparing for the way back to Belgium and spent a nice evening with candles to finalise the plan for the remainder of the holiday. It was a great opportunity to open a good bottle of Whisky I brought from Belgium which we ended up drinking a little too much off 🤕

The plan:

• Go back by car (no ferry)
• Two more days in Sweden
• Visit Helsingborg and Malmo
• Book a hotel for the final night(s). That way everyone could have a good night of sleep, an extensive breakfast before driving all the way back
• Try the drive back in one day (Corona rules for people transitting Germany)

In the morning the Sheep farm turned out to be much more awesome than we'd imagined. There was a small breakfast/lunch shop, a mini-beach to swim, you could take a tour around the farm (over 1000 sheep) and they allowed the kids to touch some of the sheep.

As we had a dinner date with my colleague in Helsingborg we had to leave for about a 1-hour drive. Annelies did all the driving where I had a chance to look for Corona rules with regards to passing through Denmark and Germany and had to find a place to stay.

The West coast of Sweden has much fewer spots to spend the night with a camper. I discovered that some of the regions also have a no-free parking rule (in contradiction with the rest of Sweden). As we agreed to go for dinner in the city centre, and we wanted to put the kids asleep at somewhat of a decent hour (Marcel is 6 yrs old), I was looking for something we could walk/taxi to from the restaurant. No success :-(

Looking at the different options I found an affordable hotel with one family room available right outside of Helsingborg and the taxi ride to the restaurant was about 25 euros. Turned out the room was really just 4 beds but luckily we had a mattress and sleeping bar in the camper. After taking a quick shower (showering 3 kids is never quick) we said hello to this great taxi driver and went to the hotel.

It was my first time meeting Brenna (my colleague) and turned out to be a wonderful night! The kids enjoyed the company of Brenna and her partner, we had great food, good laughs and some time left to explore the city centre and harbour. Robbert and Brenna had a great (Pokemon) connection. Great success!

As a cherry on the cake (and according to the plan we made 2 days earlier) we wanted to surprise the kids with a hotel with a swimming pool or sauna and Annelies and I were secretly hoping we could have a rooftop/skybar experience after the kids went to bed.

So I booked two rooms in the Clarion Malmo Hotel which turned out to be great. We had two adjacent rooms on the 16th floor with an awesome view. Because the sun was out we figured out would be best to explore the city while finding something to eat for the kids (we were planning to have a tete-a-tete in the hotel skybar).

Exploring the city we had cocktails on a terras, took a ride in the ferry wheel, found a great restaurant for the kids, practised our Voi scooter skills and danced to a DJ in the hotel that was wrapping up the LGBTQ+ conference in the lobby of the hotel.

We managed to get the kids to sleep at 20:30 for the long ride tomorrow, and after I made sure they were really sleeping, shared instructions with Robbert on how to reach us and the reception I went up to the Skybar where Annelies was waiting for me.

It was the perfect wrap-up of a one month stay in Sweden. Perfect (and frigging expensive) cocktails, good food and a wonderful view over Malmo from the 25th floor.

Sweden, we will be back!

I was scoping some changes to the website today and noticed how much better we plan and execute on changes to the website.

2010

This is the first version of the homepage created by Jesse and Frederik.

2011

This one I remember more clearly. Frederik had read a book about 'social proof' and was obsessed with adding customer faces and quotes on our marketing materials.

2012

Did you say social proof? We added quotes, logos of customers using it and were experimenting the opening title

2013

Another revamp of the website with the first time I see Elvis Presley appear rocking it on the homepage header

2014

This year was the first time we got rid of the blue/green combination making room for a more subtle color palette

2015

Yet another color scheme and the first time there is a strong focus on 'request a demo'.

2016

This is a variation of the 2015 design with better copy, different hero. The gray on gray block 'Prezly made it effortless to set up your brand story hubs' was a poor color choice as I have trouble reading the text.

2017 - 2018

This is the first time we have introduced a CMS to power the site. For the design we broke with all previous versions and started over. The result paid off.

The website stayed the same throughout 2018.

2019

Colors changed to a new palette. Part of this homepage was a version with quite some animations (see below)

Part of that page was an animation displaying the 3 key areas of the product. I remember the animation as being expensive to build, broken in some browsers and most of all very CPU bound resulting in low FPS.

2020

Same design framework as our current homepage. Back then it was powered by laravel Lumen framework

2021

Earlier this year we switched the website to be powered by Vercels Next.js. We swapped out the 'demo request' flow to a start your free trial flow.

2022

We doubled down on using NextJs and Contentful for the website. In attempt to use Prezly more ourselves (Read How Prezly uses Prezly, to run Prezly) we also integrated the /help section, the /academy and /news newsrooms.

We doubled down on the 'Turn your fanbase into Fans' and added a homepage slider to indicate you can use Prezly for different use-cases.

2023

Current homepage with a stronger focus on explaining what the product does exactly together with social proof. Hero was replaced by a slider/video component that highlights the different parts of Prezly.

Text editors are central to most online apps. While text editors used to be important for Content Management Systems (CMS), they are now an important part of many more tools such as Project Management Systems and CRM systems. Customers are rightfully more demanding when it comes to how they create content.

But building a good editor is bloody hard. You'd expect that this is a solved problem in 2021 yet so many products have a poor writing experience. As a result, content is written off-line, using tools like Google Docs, Microsoft Word or a notes app and then pasted in an inferior editor.

This is a post listing some recommendations for creating a more friendly web-based writing experience:

• Auto-save to avoid losing work
• Awesome linking experience
  • Easily link to other content in the same CMS
  • Allow different type of links
  • Highlight (and upgrade) broken links
• Use good typography
• Great support for lists
• Show pasted images inline
• Essential features done right
• Wrap long lines
• Make it fast (speed/performance)
• Support text-correction extensions
• Undo/Redo (with shortcuts)
• Good pasting behaviour

Auto-Save to prevent lost work

If we want to get people away from the 'traditional' editors we need to protect people from losing their work. No internet connection when you hit save? Browser crash?

I can guarantee you that the author will never use your editor the same way ever again if they lost an hour of their work.

Online editors should invest in techniques to make sure this does not happen, the technology is out there. Some ideas:

1. Browser Local Storage (client-side)
2. Auto-saving in the background (server-side)
3. Versioning content (server-side)

Option #2 is the option most web apps will pursue but for CMS systems that allow publishing content, it comes with another challenge which is to know which content has been published which is where option #2 comes in.

Awesome linking experience

Most WYSIWYG editors have ported the Microsoft word linking behaviour to their online counterparts. We're so used to applying a link to an element:

This is a missed opportunity with two big area's of improvement:

Easily link to content in same CMS

Most blog posts refer to previous posts or paragraphs. Forcing editors to visit their blog, find the URL/anchor and paste it as a link is such a waste of time.

A few exceptions (Google Docs, Notion) are helping writers to browse/search for other content but I'm disappointed every time I have to open a new tab to find the URL for something I want to link.

ℹ ​ Bonus points for the ability to link to anchors which I think only Google Docs can do (only within the same document).

Allow different types of links

A link used to be a few underlined words pointing to an external page. In 2021 there are so many more ways to present links (cards, embeds).

Editors could help with 'upgrading' links to an embed or card. Preferably the editor has the ability to specify how the link is displayed.

Highlight (and upgrade) broken links

The web is filled with broken links 😵 Make sure the editor indicates broken links by checking the page in the background and hinting at the status (status code).

While you're at it how about improving/fixing the link? If the server replies with a 302 redirect (for example from http:// to https://) update the link without asking the editor. It does make the web a better place!

ℹ ​ Personally, I prefer not to see the schema in any link. If a user pastes https://www.lifelog.be in your editor you'd like to see it auto-link that phrase to the webpage and at the same time change the link text (or label) to www.lifelog.be.

Use good typography

Many online editors use weird fonts and font sizes. ​ No content creator is going to spend an hour writing content in an editor that makes them squint.

Readability is a big problem on the web with many initiatives and resources to solve that. Learn about the best practices in those projects and apply them to your editor.

The example to follow here is Medium.com where the editing experience equals the reading experience.

Great support for lists

People use lists. A lot. Make sure your editor has good support for it. A list 😎of suggestions:

• support hitting tab to indent lists
• auto-detect lists once a person starts a few (or one line) with -
• allow nested lists
• shift+tab should decrease indenting
• think about how people 'exit' the list (enter+enter?)
• allow people to convert lists from bullets into numbers

Writing this piece in Bear reminds me how important the support for lists really is.

Show pasted images inline

While initially, only some editors allowed you to attach images to your posts it's 2021. People do text -> image -> text.

Regardless if one is writing an article on a blogging platform, sharing feedback on a design in a project management platform or updating an internal document in your intranet please support pasting images!

The ideal flow is that while writing the text you can just hit paste to add an image from the clipboard. Please don't attach it at the bottom of the post (I'm not drafting an email) but add it wherever the cursor is.

ℹ ​ Bonus points for auto-sizing/optimising the image or allowing controls for the editor to size/align the image

Essential Features done right

All the power features you have added to your editor (image wrapping, code editing, advanced text styles or colour picker) do not mean anything if you have not nailed the basics.

Seriously, I don't need font colours or backgrounds if I can't paste an image inline. Start with the basics before you spend time on the advanced stuff.

Wrap long lines

There has been plenty of research that a line longer than 70 characters is hard to read. While this rule is well known in web readability it's often ignored in editing experiences.

This problem is even more noticeable with full-width (focus mode) text experiences.

Use max-width in combination with optimised font size/typography for an editing experience that has good readability. It really does wonders.

Make it fast

This should not even be here but I'm adding it anyway. If your editor is clogging up my browser window (I'm looking at you Confluence) you'll never convince me to use your editor to do the writing.

Evan You on Twitter

Spend time on performance! Some people will take 1/10 of the features for 10x the speed.

Support text-correction extensions

How long did it take for google docs to support Grammarly?

There are so many good correction engines (Grammarly, slick write) out there that provide browser extensions to make sure the text correction can be done wherever you write. Surprisingly not all editors support those extensions forcing you to copy/paste your text into Grammarly just to do text corrections 🤯

Also, please don't try to build text correction yourself (maybe unless you are Google) but allow existing solutions to hook into yours.

Undo/Redo (with shortcuts)

For me undo/redo is a solved problem and much expected in any content editor. Surprisingly there are editors that do not support undoing.

Good pasting behaviour

Following the suggestions in this post is not a guarantee that people will stop pasting stuff. Spend time on figuring out what/how they are pasting and make sure it works well.

In our case, we triggered a survey the first time we detected a paste from an unknown source (weird formatting or elements). In that survey, we asked the user where they were pasting from and questions around why they didn't write in Prezly in the first place.

Results of this survey were then used to help us figure out which pasting behaviour (from which source) we needed to prioritise.

Word has been around for a long time. It's unlikely that the tips in this post would mean people trust your editor to be 1:1 alternative. Like it or not, MS Word will continue to be an enormous force behind the content that finds its way online.

However, it's also true that a lot of online editors are super annoying to content authors. While some platforms have a great tech stack and are growing rapidly they oftentimes have poor experience for long writing sessions. So it's little surprise authors actively avoid them to perform their writing.

Maybe this post is one step in the right direction

In this article, I am going to break down how this blog works. When I started this project my main requirements were 1) developer experience, 2) performance and 3) simplicity.

Update July 2022: New blog theme

The stack

This blog is a Next.js application that is pulling in content from the Prezly CMS.

Using Next, you have a few options when it comes to page rendering: “on-demand” (server-side rendering) or ahead of time (static site generation). I've opted to build all the pages posts ahead of time when the site is generated (so on every deployment).

The site is deployed on Vercel (the company behind Next). The developer experience is awesome where it auto deploys the blog on every commit/merge to main.

For analytics I decided to use Plausible Analytics which took me 3 lines of code to set-up:

Content/CMS/Deployment

This all started as a big experiment while I was trying to figure out what we needed to do to make Prezly more developer-friendly. By trying to power an (external) blog with content written within the Prezly editor it would allow me to identify the parts of the chain that need more attention.

Every time I create or write a story in Prezly it triggers a Vercel webhook which in its turn generates+deploys the site.

Because of the limited number of blog posts the rebuild takes less than a minute:

Story Renderer

The Prezly editor stores content in a rich text format (and not HTML). This is a common practice in today's Content Management Systems as this allows for more flexibility when it comes to the rendering and management of that content. There is even a standard for it.

Here is a great article (2018) about the benefit of rich content types.

On Rich Text Editors

In Prezly's case, it means that content you write in a SlateJS powered editor is stored as a JSON object in our data store. That raw content object is fetchable through the API and we provide a renderer to then turn it into HTML.

So take this example content in Prezly:

The content (starting from hi %contact.firstname%) will be stored JSON:

Github Gist: Example email campaign (slateJS)

As we're using SlateJS as an editor you can read more about the content structure (not mobile doc) in their help article. Using the Prezly provided slate renderer the code that turns this JSON object into the HTML you are reading right now looks like this:

https://github.com/digitalbase/lifelog.be/blob/main/components/Article/Article.tsx#L36-L40

How content is rendered can be customised by feeding options into the renderer which I had to use to display code snippets (see below).

Other Pages

For other pages such as the home page, the list of blog posts and sitemap I used the Prezly Node SDK to do some very simple API fetching.

For example, the home page that lists the latest 3 articles (source code):

https://github.com/digitalbase/lifelog.be/blob/main/pages/index.tsx#L32-L42

Which by itself is just a simple wrapper to list content

https://github.com/digitalbase/lifelog.be/blob/fbb7d1d2fb56f0f2369b50e4606f975fbf49243a/src/providers/prezly.ts#L40-L63

Embedding Code Snippets

The Prezly supports embeds by making use of Iframely which natively supports github embeds (see JSON sample above). But if you have a lot of code to show off copy-pasting code into secret Github gists is cumbersome.

So I wanted to be able to show off code in a github repo or branch and Googling a solution for this got me to emgithub.com which looks to be exactly what I wanted.

Integrating the embed code in within the project was pretty clunky (dangerouslySetInnerHtml, embed.js being calls numberous times, ...) so decided to extract the code. Actually, my colleague did it for me.

https://github.com/digitalbase/lifelog.be/blob/main/components/GithubSnippet/GithubSnippet.tsx

So what the code is doing:

• fetching the raw github code (client side) using https://raw.githubusercontent.com
• use 'react-syntax-highlighter' to show a code pane
• add 'view raw' and 'copy to clipboard' functionality. Stole from stackoverflow

Styling

When it comes to styling I think I overdid it. I decided to use ChakraUI (as an experiment) but in the meanwhile I have been playing around with TailwindCSS (and more specifically with Just in Time generation). Now I want to throw out ChakraUI and switch to vanilla tailwind.

There are some upsides to using ChakraUI. For example, check out the source code for this hero component on the homepage:

Overall I feel using Chakra forced me to learn another syntax/way of doing things and I might be better off investing this time in properly learning TailwindCSS which can do the same stuff anyway.

Todo list

A list of things I want to do with the blog

• Use theme-starter boilerplate code to fetch content
• Score better on Lighthouse Audit tools
• Allow paging from home page
• Support Search
• Implement subscribe functionality (stay updated)
• Improve SEO/meta tags
• Add RSS feed (and any other feed protocols people use)
• Get rid of ChakraUI
• Make better use of Uploadcare.com (using uploadcare-image)
• Bring back sitemap.xml
• Fetch intro text from newsroom boilerplate (make customiseable)

In a previous post I tried to find the best newsroom based on unbiased signals such as search traffic, lighthouse scores, accessibility and page speed.

Now I'm interested in the ad stack of those newsrooms: Are they all using Google Analytics? Who is using segment.com and on average how many ad trackers can we detect?

Let's dive in.

By using a combination of Netcraft Site Report and two chrome plugins (Whatruns and Wappalyzer) i went through the top-20 sites one by one and filled in these columns:

• Frameworks: Detected frameworks both on server and client excluding things like modernizr, wordpress (see next column) or small client libraries
• CMS: Content Management System powering the site. In the era of Headless CMS sites, CDN's and better devops practices this is hard to spot
• Main Language: PHP vs ASP vs Python based on the framework used
• CDN: Content Delivery Network to speed up page serving globally. Not always detected
• Tracking: Ad-tech/Tracking libraries used detected by the chrome plugins.

The results

Screenshot of the results below but use this airtable link if you want to see the raw data

Learnings

It's only 20 sites but lets try and see if there is anything interesting to learn,

Frameworks and CDN

• Wordpress powers 7 of the top-20 newsrooms
• jQuery is on 13 of the top-20 newsrooms
• Bootstrap is on 4 of the top-20 newsrooms
• 2 sites are using Angular
• 1 site is using nextJs

Hosting & CDN

As expected the major CDN players are powering those sites with 35% Akamai and the rest evenly spread between CloudFront, Google CDN, fastly and such.

Four sites (Revolut, Walmart, Honda and SAP) did not show a CDN but they might be whitelabeled/custom CDN set-ups.

Web Servers are hard to see nowadays but I think it's safe to say that the majority of sites will be powered by Apache or Nginx. Nothing interesting here.

Ad Tracking

• 14 sites are using Google Analytics
• 7 using Google Tag Manager
• 5 using New Relic
• Usual suspects: FB, Twitter, LinkedIn pixels, Adobe SiteCatalyst or Analytics, ​
• Only one site (Apple) has no ad-tech/trackers
• Newsroom with the most trackers is Paypal with seven ad trackers
• Only one site that has privacy focussed analytics which is Paypal, but then they are running that besides Google Analytics

With help from Prezly colleagues, customers and twitter I now have a list of about 60 newsroom URLs from well-known brands, but which ones are the best?

In this post, I will explore different ways to score those newsrooms on their technical foundations. Obviously, a good newsroom is about a lot more than performance and accessibility but let's start with the basics.

Here are the criteria I will use to order the list:

• Lighthouse Score
  • Page Speed
  • Accessibility
  • Search Engine Friendliness
• Ahrefs.com data
  • Url Rating
  • Domain Rank
  • Referring domains
  • Search Traffic Estimate

Assigning weights to those different criteria and averaging it in a single number will result a pretty accurate score around the technical foundations.

Lighthouse Score

There is a great way to measure some web fundamentals (performance, accessibility, best practices and SEO) and it's called Lighthouse. It actually comes with every chrome install by opening dev tools and clicking the Lighthouse tab that allows you to generate a report of any site you visit:

Page Speed

A critical component in what makes a good newsroom is speed. Speed is the killer feature. Running a lighthouse score on the Nike newsroom for example would, at the time of writing (March 8, 2021) give you a score of 62% doing a performance audit with a mobile device:

Running the lighthouse audit for almost 100 newsrooms would take me too much time but there is a way to run the same audit through code (using node).

Here is the code I used to walk through all the newsrooms and run both a desktop and mobile audit and feed the scores back to the airtable sheet:

Github Gist: performance.js

Running the audit took about 30 minutes and did crash Chrome a few times while it was running. The average desktop performance score is 41% with the median being 39%. Not a single newsroom is scoring over 80% in desktop performance.

The fastest newsrooms on the list: Revolut, Airbnb, Walt Disney and Netflix. Not surprisingly all companies that understand the importance of speed

Gijs Nelissen on Twitter

Accessibility

A second way of scoring the sites is accessibility. Here is how w3c describes accessibility:

When websites and web tools are properly designed and coded, people with disabilities can use them. However, currently many sites and tools are developed with accessibility barriers that make them difficult or impossible for some people to use. Making the web accessible benefits individuals, businesses, and society. International web standards define what is needed for accessibility.

Lighthouse can score accessibility with the same audit tool returning a score that is a weighted average of a different set of accessibility audits. I used pretty much the same code to run both an accessibility and a SEO audit for all different newsrooms:

Github Gist: airtable_lighthouse.js

This audit took a lot less time to run. The audit was surprising as the top-3 was different from the performance audit with Nestle, Visa and Starbucks leading by example with +98% scores.

Gijs Nelissen on Twitter

Search Engine Optimalisation (SEO)

The time spent on small improvements that benefit the on-page SEO paints some kind of picture to what level of detail was spent on a site. Here is an example lighthouse audit of a site like the Starbucks story:

The code to run that audit is posted above and all the results are available in the airtable sheet. Facebook, Instagram (same engine?), and Airbnb all score 100% on SEO.

In the paragraphs below we'll be using ahrefs.com to go deeper into the SEO ranking.

Gijs Nelissen on Twitter

Averaging those tech scores here is the top-15 newsrooms so far:

Ahrefs.com

Ahrefs offers a set of tools allowing you to audit any site on the internet. From their website

Ahrefs is an All-in-one SEO toolset, with free Learning materials and a passionate Community & support

In our case we want to get a few indicators about the collected newsrooms. I could look at 50+ different data points but for the sake of simplicity I will keep it to these:

• URL Rating (UR) shows the strength of a page's link profile on a 100-point scale. The bigger the number, the stronger a page's link profile is.
• Domain Rating (DR) shows the strength of a website's backlink profile compared to the others in hrefs database on a 100-point scale.
• Referring domains are websites from which the target website or web page has one or more backlinks. For example, if a web page has a backlink from the New York Times, then it has one referring domain. If it has a link from the New York Times and Forbes, that it has two referring domains. If it has two backlinks from the New York Times, then it still has one referring domain.
• Search Traffic Estimate is an ahrefs.com estimation of how much organic search traffic your target website, subfolder or URL gets each month.

As I don't want to fill in those numbers in the Airtable I upgraded to an Ahrefs.com API subscription and pulled in the data. Here is the code:

Github Gist: ahref_airtable.js

I know I can make this script much faster by parallelizing the request (feel free to suggest!) but my brain doesn't function well in an asynchronous world 🤯

URL and Domain Rating

Clear winners in URL and Domain rating are Apple, Facebook and Youtube. In this case, I believe online/technology brands have a clear advantage over their 'offline' counterparts.

While the bottom of the list has more what i call 'offline' brands such as Pepsi, Ford, Budweiser or Nestle. Small surprise in that bottom 20: Google and Microsoft 😬

Referring Domains

I have normalised the absolute domains (count of absolute domains linking to this page) to a percentage value. Apple has an astonishing 26 000 domains linking to their newsroom and facebook 14 000).

Because Google and Microsoft are at the bottom of the list I am suspecting something is wrong with the crawled ahref data.

Search Traffic Estimate

The search traffic estimate is an interesting number but not reliable for the final rankings. Ahrefs tries to guess the number of visitors/month the newsroom would receive by using SERP rankings and other SEO signals.

The median of all newsrooms is 540 visitors/month. Most newsrooms are in the same ballpark but outperforming everyone else in the list are Facebook with 14 million visitors/month and Youtube approaching 3 million visitors/month.

I will not use the search traffic estimate in the final summary as I noticed it wasn't trustworthy. 14 million?!

Summarizing

To summarise all this I decided to add weight to the different criteria.

• Lighthouse Score (60%)
  • Page Speed (70%)
  • Accessibility (20%)
  • Search Engine Friendliness (10%) -> also in ahrefs.com
• Ahrefs.com data (40%)
  • URL Rating (60%)
  • Domain Rank (10%)
  • Referring domains (30%)

Overall Lighthouse is taking 60% of the final score while ahref.com data gets 40%.

The results

It took a while to apply the weights in the Airtable formulas but I got there in the end.

At the moment of writing here is a list of the best 10 newsrooms based on the criteria and code outlined in this post:

Want to suggest another newsroom to include? Please suggest it

While I'm searching for inspiration to design, build and integrate the best possible newsroom in Prezly I wanted to share the plans on how we're want to do this.

We want to include our customers and anyone that is interested in building customer newsrooms in the process. I believe this transparency will result in greater overall quality and hey, maybe we'll get the attention of a big brand or awesome designer while we're at it.

Open-Source

One of the key goals is to make the whole project open-source. That starts with picking the right license for all the work after which we'll open-source the entire thing. That includes:

• Wireframes
• Figma Files
• Scope documents
• The codebase

A side effect of this approach is that customers that want to modify their newsroom experience can do so by starting with one of our base themes. It also means bugs and improvements can now be made by more than the Prezly newsroom team 🎉.

Self-Host

Today all of the newsroom code is heavily tied into our monolith. We've chosen a multi-tenancy approach where a single codebase powers all (10 000+) newsrooms. The difficulty with this approach is that any customisation for a single customer or base themes has to go through the main repository. This also prevents us from collaborating with customers when it comes to theming.

Another goal in this project is to allow customers, or anyone interested in using the theme to self-host their newsroom on existing infrastructure, Vercel, Netlify or any other preferred host can do so.

Awesome DX

The ecosystem around frontend development is changing at a rapid pace. I believe a critical ingredient of involving themes and developers in the ecosystem is to have a world-class developer experience.

An excellent experience while working on a theme means has to have things like hot reloading, super-fast local environment, easy installation and enough freedom around theming choices such as which framework to use.

Outside of the pure developer experience, there are a lot of things we can do to make Prezly more enjoyable for developers such as improving API docs, providing different SDKs, reliable documentation, starter kits and interactive tutorials.

Break up in phases

It would be arrogant to believe that we'll come up with the best solution for any newsroom use case. Here is an incomplete list of the functionality we currently support:

• 60 Languages (i18n localisation)
• Gallery functionality
• Categories and Tags
• CSS/JS customisation
• Segment.com, Google Analytics, GTM, Google webmaster support
• Attachments and Contact Cards
• Search
• Embedding tweets, instagram or other embeddable content
• Sharing buttons + short urls
• Subscribe functionality
• Cookie bar + GDPR tools

To give us enough freedom to experiment and focus on user experience we're breaking this project up into different phases. By not worrying about how a cookie bar or language switcher is ultimately going to come about we're hoping we can catch more speed and work in some kind of an MVP approach.

To allow for that the different themes need to be aware of all the functionality they support to prevent customers from enabling a theme that does not support the functionality they need.

Let me know what you think!

Is 'newsroom expert' a job title? In the last 8 years, I have been involved in planning, designing, building, migrating and hosting a lot of newsrooms. From small startups and NGO's all the way up to large brands like Sennheiser, AXA or Shopify.

Within Prezly we offer three newsroom themes that I'm not super proud of. The first one has been there for almost 8 years with minimal maintenance and upgrades. In fact, some of our clients have customised newsrooms that are notably better than we offer our customer base.

In the next 3 months, we're going to fix that.

Examples / Inspiration

To prepare for this project I wanted to get some inspiration from the best newsrooms out there. Googling my favourite brands with search queries like 'Apple newsroom' or 'Red Bull newsroom' turned out to be really underwhelming.

What are we looking for?

What is a newsroom? A website with a list of news items/stories listed in chronological order? So like a blog? Or a magazine?

Please help by suggesting the newsrooms you really like.

Use Cases

Looking at the use cases of Prezly I've split the research into three different use-cases:

1. Brand newsroom: Site with a listing of important company news and stories
2. Blog: A lot like a newsroom (1) but more focus on text and author.
3. Other: Anything else that is about some kind of chronological listing of content. For example a website to announce podcast episodes, or a cooking blog.

Brand Newsroom

To research brand newsrooms I used the top 50 most valuable global brands together with the 500 favorite Millennial brands to search for relevant results. All the newsrooms that are noteworthy were added to an airtable sheet with a rough rating to do more research later.

It might surprise you but the results browsing through all those newsrooms were really underwhelming. To prove it lets take the 10 most valuable global brands with their main newsrooms:

• Apple - www.apple.com/newsroom
• Amazon - press.aboutamazon.com
• Microsoft - news.microsoft.com
• Google - www.blog.google
• Samsung - news.samsung.com/global
• Coca-Cola - www.coca-colacompany.com/news
• Toyota - global.toyota/en/newsroom
• Mercedes - www.mercedes-benz.com/en/newsroom
• McDonald's - corporate.mcdonalds.com/corpmcd/our-stories.html
• Disney - thewaltdisneycompany.com/news

Only a few of those check all the boxes when it comes to design, content organisation and performance. But we haven't even talked about performance, accessibility or privacy controls.

I am looking for more examples of good looking Brand newsrooms. Please help by suggesting your own in this form.
​

All research (Lighthouse scores, Design rating, Accessibility score) will be shared in this open spreadsheet.