'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

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.

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.

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?

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.

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

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!

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)