DEV Community: beacampos

12 Ruby Gems to make your Ruby coding smoother

beacampos — Tue, 22 Aug 2023 17:25:29 +0000

How many Ruby gems do you have currently installed?

With around 50 new gems released daily, it is common to use trending libraries for managing everyday tasks. You probably use Devise for authentication, Cancan for authorization, Kaminari for pagination, or run tests with Rspec.

From time to time, it is efficient to research new solutions. For this purpose, we have selected 12 gems in several important categories that you should try. All of them have been released within the last two years or three, are regularly updated, and have already gained the trust of Ruby on Rails developers.

We’ve specified the release date and a number of downloads (within a given period of time) according to the Ruby Toolbox.

Active Record plugins

Pagy

Pagy is an agnostic library for pagination. It is written in plain Ruby and is compatible with any framework and collection type.

It is a modern solution that significantly outperforms popular packages. It is 40 times faster and 36 times lighter than Kaminari!

In addition, Pagy is well explained with plenty of guides.

Date of first release: February 12, 2018. It has gained 1 million+ downloads within two years.

Code quality

Undercover

Its creators state that Undercover is “Like RuboCop but for code coverage.” It detects recently changed code blocks that have to be covered with tests. Undercover can be used both locally and in an automated build.

Undercover is not super popular, though it is quite a helpful library, especially for big projects with legacy code.

Date of first release: May 10, 2018. For the first two years, it had just 68k+ downloads.

Developer tools

Rexe

The command line executor is designed to simplify your Ruby command line by removing low-level configuration parsing and formatting.

Rexe helps efficiently merge shell scripting and Ruby on the same command line.

It is a small script with a number of applications, some of which are pretty funny. For example, you can use it as a simple calculator or a currency converter 🙂

Date of first release: February 3, 2019. For the first 1.5 years, Rexe was downloaded 8k times.

Optimist

Optimist is a command-line option parser that does the parsing and then provides you with a hash table of options. It helps you to save time and write less code. It also automatically generates help pages. On their wiki, you will find a few examples of the commands use and short options generation.

In the end, we like the name! And we are not alone here – the gem is very popular.

Date of first release: August 24, 2018. For the first 1.5 years, Optimist gained 8 million+ downloads.

Quarantine

Quarantine manages flaky tests by detecting and disabling them. It also helps automate testing workflows. Quarantine is compatible with the Rspec framework and Buildkite CI pipeline.

You can also set up a Jira workflow to get automatically created tickets in Jira for flaky tests. Once the ticket is closed, the test is removed from quarantine.

Date of first release: April 22, 2019. Within a year, Quarantine was downloaded 175k+ times.

Graphics

Apexcharts

Apexcharts is a library for creating amazing web charts in your Ruby app. It’s just beautiful: you will find numerous examples of completely different types of charts.

To build the data for a chart, it is recommended to use groupdate gem.

Date of first release: June 13, 2019. In a year, this gem got 14k downloads.

Encryption

Lockbox

The Lockbox gem is a modern and user-friendly way to encrypt your data.

It is secure, simple, and compatible with other libraries. Another argument for trying it is that it is easy to migrate to Lockbox from another library.

Lockbox works perfectly with Devise, which is the most popular authentication framework for Rails.

We have recently posted the experience of our friends from Planet Argon with setting up emails to reset a password with Devise (and Mailtrap, of course!) – check this blog post for more info.

Date of first release: January 2, 2019. Within 1.5 years, Lockbox was downloaded 127k times.

Machine learning

TensorStream

Do you use machine learning algorithms? Then consider the TensorFlow implementation for Ruby. It is not new, but we found it worth sharing here.

TensorStream is an open-source framework with no TensorFlow dependencies. With its programming style close to TensorFlow and Ruby syntax, you can build and run machine learning models in GPUs and CPUs. It comes with a pure Ruby and OpenCL opcode evaluator. An OpenCL backend is provided in a separate gem.

Date of first release: May 11, 2018, and 12k+ downloads over 2 years.

Monitoring

Yabeda

This Ruby gem is a framework for setting up monitoring in your Ruby app. Yabeda collects statistics on your app performance and allows you to export metrics to several monitoring systems.

In addition, there are many plugins for Yabeda to configure monitoring with ease.

Date of first release: October 17, 2018. Over roughly 1.5 years it was downloaded 128k+ times.

Deployment

Tomo

Tomo is an SSH-based CLI tool for deploying Ruby apps. Its distinguishing feature is its independence from Rake, unlike the majority of Ruby-based deployment tools. Tomo is presented as an alternative to Capistrano, Shipit, and Mina.

It has no required gems dependencies, but batteries are included, as well as opinionated defaults and simple DSL.

Date of first release: June 17, 2019. For less than a year, Tomo was downloaded 11k+ times.

Testing

FakerMaker

FakerMaker is a simple factory builder that creates disposable objects for testing. It is created to supplement the Thoughtbot library for cases when you test an API, don’t use Rails, or don’t have model classes.

It is recommended to use FakerMaker with a Faker gem (no dependency, though).

Date of first release: March 5, 2019. In slightly more than a year, this gem got 19k+ downloads.

Web apps, services, and interaction

Cache Crispies

Cache Crispies is a gem for JSON serialization that has a built-in caching. It doesn’t limit you with the format of JSON responses. It’s fast and flexible and has a simple DSL.

Date of first release: July 12, 2019. 50k+ downloads were reached in less than a year.

Wrapping up

Let me know what you think about this list by sharing it and your experience!

And Mailtrap is always here for safe and efficient testing of any kind of email you need to send from your Ruby app. In fact, Mailtrap is technology agnostic – that’s why there is no Ruby gem for it. You can easily configure Mailtrap as a regular SMTP server or integrate it with your app via API and enjoy email testing, previewing, and debugging in a development or staging environment.

As always, thanks for reading! Visit the original article and much more helpful guides and blogs on mailtrap.io 🔎💻

All things Email Bounce [+ best practices]

beacampos — Mon, 21 Aug 2023 17:04:27 +0000

Have you ever sent an email only to get an automated note saying it bounced back? If so, you’re not alone, just about everyone has experienced this. In fact, email marketers deal with this all the time.

What is a bounce, and what are the common reasons behind it? What measures can be taken when numerous emails are bouncing?

Let's dive into the world of email bounces and cover all of these questions.

What is an email bounce?

An email bounce occurs when an email service provider (ESP) tries to deliver an email to the recipient’s email server, but it’s returned without being accepted, resulting in an automated bounce message to the sender indicating a delivery error. There can be a variety of reasons why an email bounces, but more on this later.

Imagine a small business owner sending out a mass email to promote a new product to a list of 100 potential customers. From that list, one or two emails bounced. Now you might ask, “What’s the big deal?”… And you’re right; chances are two emails are not going to have much of an impact.

However, if, over time, the business expands and the email list grows to 10,000 potential customers, the same ratio of bounced emails would become a much larger problem. A high bounce rate could lead to the business’s emails being marked as spam, resulting in a reduced delivery rate and visibility for future marketing efforts. So it’s essential to keep track of bounced emails and the reasons behind them. This is where an email bounce code comes in handy.

What’s an email bounce code?

Part of Internet Message Format standards, email bounce codes, as old as emails themselves, are a set of numbers assigned to an undeliverable email message that indicates why the message wasn’t delivered.

Here are two code examples that Microsoft Outlook users or anyone using Azure in their email infrastructure might see:

554 5.2.122: The recipient has exceeded their limit for the number of messages they can receive per hour. For more information go to…

452 4.3.1: Insufficient system resources (TSTE). For more information go to…

Generally, codes that start with a 5 indicate that the error is permanent, and those that start with a 4 mean it’s a temporary issue.

With these codes in hand, it’s easier to manage your rate of emails bouncing and make necessary adjustments.

How does email bounce impact email deliverability?

When an email bounces, it sends a negative signal to the email sender’s server, potentially affecting the sender’s reputation and overall deliverability in the future. Additionally, they can negatively impact the recipient’s engagement metrics, such as click-through and open rates, leading to a decrease in email effectiveness.

Knowing what causes an email to bounce can help reduce errors and improve deliverability.

Types of email bounces: The causes and how to handle them?

Bounces can happen for numerous reasons. The simplest approach to understanding and dealing with them is first to categorize them:

Soft bounce – temporary glitches obstructing delivery.
Hard bounce – permanent failure in delivering an email. Once you understand the bounce type, you can have a deeper look at understanding the reasons and what action needs to be taken to avoid them moving forward.

Soft bounce

A soft bounce is an undelivered email message that usually indicates a temporary issue related to the recipient’s mailbox or account rather than an issue with the sender. Some of the main reasons why soft bounce happens are:

Full Inbox

When the recipient’s inbox is full, the email server will bounce the email back to the sender. This means that whenever you get a bounce message with a code that indicates full inbox as the reason, it still makes sense to keep that email address on your list. Once the inbox is cleaned or extra storage is added, the recipient will be able to receive new emails.

However, be mindful that if you keep getting this error from the same email address after a few delivery attempts in a span of the campaign cycle, chances are the inbox is an abandoned one.

Server Overload

This type of bounce happens when the recipient’s email server is experiencing high traffic volumes. It’s crucial to keep an eye out if there is some kind of a pattern.

If a significant number of emails to a specific email provider (e.g., Gmail, Yahoo, etc.) are being bounced back with the reason “server overload,” it’s likely that the recipient’s email server is experiencing high traffic volumes at a specific time of day or day of the week. To increase deliverability rates to a specific email provider, it’s important to adjust email sending schedules accordingly.

Email Size

This soft bounce is caused when the email being sent is too large for the recipient’s email server to handle.

Some email clients, such as Gmail and Microsoft Outlook, have a maximum email size limit of 25 MB, while others may have a limit as low as 10 MB. It is essential to keep this in mind and adjust your email size accordingly to avoid soft bounces due to email size.

Similar to server overload, keep an eye out for patterns. One solution to prevent such bounces from a particular ESP is to break large emails into multiple smaller emails or split the content into smaller chunks and send it over multiple emails.

Email Filtering

The recipient’s ESP can sort incoming emails into categories based on their content, sender, and other factors. This reduces the amount of spam or unwanted emails but can also lead to legitimate emails bouncing. Here is an example of a bounce message you get from Gmail:

421 4.7.0: Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily blocked. For more information, visit Prevent mail to Gmail users from being blocked or sent to spam.

This code begins with a 4, meaning it’s a soft bounce, but regardless, take heed of any warnings regarding email content. Neglecting such notifications over time can result in a hard bounce that’ll be a much more severe problem. Once this becomes a hard bounce due to content issues, an ESP will simply block your domain, and getting it unblocked is no walk in the park.

To avoid such problems, always act promptly by reviewing the content of the email and ensuring that it complies with the recipient’s mail server spam filter rules. If needed, take the initiative and reach out to the recipient’s ESP for assistance and advice on how to avoid your emails landing in the spam folder.

Temporary Server Error

A simple network outage can also cause a temporary server error, leading to a bounced message. So just resending the email, in most cases, will work.

Hard bounce

Suppose you receive a permanent email delivery failure (hard bounce) notification from a mailbox provider. Unlike in most cases with a soft bounce, resending the message later will not work and will actually damage your sender’s reputation.

Before resending anything, changes must be made to either the message or the recipient’s address and maybe even to your email infrastructure.

Let’s take a look at some common cases of hard bounces that email marketers face:

Invalid or Non-Existent Email Address

If an address has typos, is missing crucial information, or the email account simply doesn’t exist anymore, it’ll result in a hard bounce. To prevent this type of bounce, verifying your email list regularly and removing any invalid email addresses is essential.

Of course, anyone can make a typo in their email address, so an occasional hard bounce due to this is no reason to be alarmed. What is a red flag, though, is seeing that this type of bounce happens regularly during an email marketing campaign. If that’s the case, review how you collect and store your email list.

Another point to remember is that simply deleting email addresses from your subscriber list is only sometimes the first thing to do. It’s possible that your customer/app user just got a new email address and still wants to get emails from you. So always check if there is a way to remind the person to update their email address. For example, this can be done via an in-app push notification.

Poor Email Authentication

Issues with email authentication can often lead to hard bounces. But the truth is that there is no reason to have these types of bounces if the proper steps are taken. Several email authentication protocols can easily be implemented to help prevent these bounces, such as DKIM, SPF, and DMARC.

If you already have all of the protocols integrated, it’s still possible to get messages that say the bounce happened due to poor compliance with one of the protocols. This usually means that there is some sort of an issue with authentication settings, and the recipient server is blocking delivery from your domain or, even worse, IP address.

The good news is that most of the time, reviewing and adjusting authentication settings will quickly fix the issue. The bad news is that this type of bounce can still happen even after all the settings are corrected. This is because your email domain name has already been picked up by a credible blacklist that an ESP uses. If this is the case, you’ll need to figure out what blacklist it is and make your case with the admins to be removed.

What is a good email bounce rate?

When considering the effectiveness of an email campaign, it’s essential to understand what’s considered a low bounce rate. Most marketing tools have a campaign monitor and some automation that calculates and shows your bounce rate, but it’s still important to know how it’s calculated.

Let’s say you sent 800 emails successfully, while 20 were undeliverable. The bounce rate, in this case, would be:

(20 / 800) x 100 = 0.025 x 100 = 2.5%

This means that for this campaign, you had a slightly high email bounce rate of 2.5%

Generally speaking, for any marketing effort to be successful, you should target an average email bounce rate of less than 2%. By following several key steps, you’ll be able to keep that 2% benchmark and improve the effectiveness of email marketing efforts.

With a lower bounce rate, you can expect to see an increase in conversions, higher engagement rates, and a more successful email marketing campaign.

Use a double opt-in process

This is a process of sending a confirmation email to each new subscriber, requiring them to confirm their subscription before being added to your email list. This might seem like an unnecessary extra step, but nothing is worse than inactive subscribers. Having valid email addresses that want to get your content will increase conversions and higher engagement in the long run.

Monitor your bounce rate regularly

Use analytics tools to track your bounce rate and identify any patterns or issues that may be contributing to a high bounce rate. Make changes to your email strategy as necessary to improve your results.

Optimize your email for deliverability

Ensure that your emails are formatted correctly, don’t come across as spammy, and that their content is valuable and not over-promotional. No one likes spammers, so remember that the subject line is the first thing people see! So pay extra attention to what is written there, otherwise, the first thing people will do is search for the “Unsubscribe” button. An excellent method to determine which type of subject lines work best is to run A/B testing and analyze the open and click-through rates of the same email with a different subject.

Avoid email bouncing: the role of email infrastructure.

The success of any email marketing strategy hinges on properly functioning email infrastructure. This is why it’s important to have a solution to monitor and reduce bounce rates.

Mailtrap is an Email Delivery Platform that lets businesses and individuals test, send, and control their email infrastructure in one place. The platform consists of Email Sending and Email Testing products.

Email Sending provides developers with a stable email infrastructure for email sending and email performance monitoring that comes with high deliverability rates by design.

Our Email Sending comes with two sending options: SMTP for quick and easy integration with any application to start sending in seconds, and Email API for greater flexibility.

Mailtrap Email Sending lets you control your email performance with unique monitoring tools such as helicopter-view dashboards and drill-down reports with detailed stats on mailbox providers:

G.Workspace
Gmail
Microsoft 365
Outlook
Yahoo

Furthermore, you can see email categories and extended email history with historical data up to 60 days of email logs, and detailed stats.

Email Sending is equipped with a robust monitoring system to keep track of bounce rates and provide detailed statistics. The critical alert system that immediately notifies you if your bounce rate has increased is based on extensive cross-industry research conducted by Mailtrap. This research determines the threshold values. Currently, a bounce rate between 2-5% is considered a warning level (yellow), while a bounce rate greater than 5% is considered a critical level (red).

The system helps you stay informed and proactive in maintaining a healthy email campaign. Additionally, you can select specific recipients to receive Deliverability Alerts notifications about them via email or integrate alerts with Slack for convenience.

For example, the above chart displays a sudden increase in bounce rate above the 5% threshold on March 17 and between 21-23, triggering a warning and prompting the user to review this data. This also means that a deliverability alert was sent regarding this email campaign performance, notifying the user of the sudden drop in deliverability metrics.

Using Email Testing, a safe environment to inspect and debug emails in staging before they are sent to recipients, you can quickly validate your email’s HTML/CSS, check how emails render across different devices, and review raw email data.

On top of that, Email Testing lets you analyze email content for spam score and if your email server has been blacklisted.

In conclusion, understanding email bounces and their causes is crucial for maintaining good email deliverability and avoiding negative impacts on your email marketing efforts. Keeping track of the bounce codes and adjusting your email-sending practices accordingly is essential, whether it’s a temporary or permanent issue.

Using the right tools for regularly monitoring bounce rates and ensuring your email infrastructure is robust and up-to-date can go a long way in maintaining good email deliverability.

Hopefully this guide was helpful! 🤗 This was originally posted on mailtrap.io where you can find much more on email testing, sending and controlling. See ya

Outsourcing Product Development? Where to?

beacampos — Thu, 27 Jul 2023 10:44:03 +0000

If you loved the last post about picking a product development partner, this time we're suggesting some companies you can start your research with. Enjoy!

Product management is vital for any company thinking to create and deliver digital products. One needs to monitor all stages of product development: from conception and design to launch and even post-launch analysis. It can be daunting and challenging.

That is why turning to a experts, in this case, a consultancy agency, can save time, energy, and resources. We have singled out the top 9 product development companies that know how to develop a product in line with budget, within the deadline, and that will meet customer needs.

Oh, and apart from our own description, no one asked for a spot in this list. Real just recognizes real.

Railsware

A reputed product studio with over 16 years of experience. It started as a software firm and grew into an expert product company. The brand offers end-to-end solutions covering software development, design, data analytics, and the major one - product development services. A team of 150 professionals shares the core values of lean engineering and human-centered design.

The vision of the company is to create meaningful products that will bring value to the end user. They have a diverse service portfolio with three products of their own: Mailtrap, Smart Checklist, and Coupler. Railsware has a number of successful clients’ projects including Calendly, BrightBytes, Office Space, Google+Axe, and Philips Directlife.

thoughtbot

A talented team of 102 product experts helping develop successful products. From initial strategy to product management - this company has it all to create a new customer-ready product or polish the one you already have. The company offers a wide range of services including product design, mobile optimization, usability audit, and iOS/Android development.

As one competitive advantage, thoughtbot has clients in many industries like health technology (Healthmatch 360), technical and business assistance (Harvard Business Review), eCommerce (LOLA), and even government (Branching Minds). The company is constantly improving as well as sharing knowledge with others.

EMERGE

This company specializes in the domain of B2B product consulting and strategy as well as design and development services. According to LinkedIn, a team of only 14 employees builds outstanding digital products that customers enjoy and turn for more. Among their notable clients are LEGO, Mercedes-Benz, Starbucks Coffee, Microsoft, and TARGET.

A small but well-seasoned and experienced team of experts has human-centered design thinking. For over 20 years, this team has been working closely together with their clients to deliver the ultimate customer experience. Along with deep market research and road mapping the company prioritizes iteration and testing to produce the desired results.

ThoughtWorks

A prominent technology consultancy with headquarters in Chicago and offices in 18 countries worldwide. The company grew from a small team to a leading expert with 30 years of experience in customer experience strategy, product management, design, and development. Now it employs around 11581 talented team members that share similar values. The pursuit of excellence is one of the core values leading to exceptional digital products.

They have clients in many fields including cleantech, finances, healthcare, not-for-profit, eCommerce, and others. Etsy, REA Group, Xenex, Porsche, and Qantas are among their diverse clientele. ThoughtWorks' experience allows them to grow and scale products of different difficulties. The company delivers agile solutions together with its partners: AWS, Google Cloud, and Microsoft.

IDEO

A creative design company is known for innovative solutions for human-centered products. A talented team of 1331 employees consists of designers, engineers, entrepreneurs, researchers, and more. They foster design thinking to devise products that will both meet the needs of customers and aim for business success.

The company handles complex challenges in various industries including education, environment, energy, health, media, and many others. It works with reputable clients like The Rockefeller Foundation, The Bill & Melinda Gates Foundation, Swarovski, and American Family Insurance. IDEO aims at a better future, so they don’t work for, they work with their communities, organizations, and companies to create a decent product.

Miew

This is a prominent development studio with 27 bold and creative employees who are ready to solve complex challenges. The company focuses on product design and development from the initial idea through launch. Branding, native & web apps, audit, UX/UI design, and marketing automation are just a few among the wide range of services they offer.

The company’s deep expertise is demonstrated by tons of successful projects for varied industries. They develop agile solutions for Auto & Transportation (BMcar, Ubirider), B2B SaaS & Tech (Quobis, Connected Robotics, HypeLabs), Events & Entertainment (Comic Con, Last2Ticket), and many other fields.

ALTR

The company’s core specialty is automated data access control and security. Located in the US it was founded to protect data privacy. A team of 59 employees is expert in keeping sensitive data safe. From businesses to public organizations ー their customers safeguard data with ALTR data governance platform. Companies like Q2, AstraZeneca, girl scouts, REDWOOD, Turners, and Cadence Bank choose to govern data with ALTR solutions.

Their partnership with Snowflake, Matillion, and Tableau enables seamless and secure data migration and analytics. On top of that, the company is recognized by many awards including Big Awards for Business 2021, Best of FinXTech Awards Finalist, and Texas Best Startup.

Think Company

This design and technology consultancy stands better in crafting digital tools. An experienced group of 134 employees works together to enhance people’s lives. The company has a long history starting in 2007. Sixteen years later ThinkCompany is recognized by Forbes, Philadelphia 100, and Inc500.

They have have built roadmaps for well-known clients such as Johnson & Johnson, COMCAST, Eventbrite, Thrive, and Vanguard. A wide range of services is among its top advantages. From in-depth product and service diagnostics to service design, from technology consulting to accessibility audits ー anything that is needed for a successful digital product.

Z1 Digital

A product studio with 7 years of experience, 93 employees, and over 100 successful products. They deliver high-quality solutions together with expert partners such as Tiny, Dribble, Metalab, and Flow. The company helps businesses research, design, code, and scale products to deliver a top-notch experience.

Thanks to their multifunctional approach they have a number of satisfied clients in various industries including software (Remotely), entertainment (Vimi), finances (Makara), insurance (Marble), team management (Murmur), and many others.

Wrapping up

I hope this list of product development companies will be helpful for you to find the one that truly suits your needs! Or even just to let you know there are some great pros out there who could make your vision come to life. All the companies mentioned live up to their reputation and deliver agile solutions for the rapidly changing technological landscape. 🚀

Are there any others you think SHOULD be in everyone's top picks? I'm curious.

Tech Debt: how to spot it and avoid it

beacampos — Thu, 27 Jul 2023 10:32:29 +0000

Hi! I'm back with another guide straight out of the oven, by the expert tech-chefs at Railsware.

Technical debt is something that every tech company grapples with. Most of us would rather ignore the debt than confront it, but this leads to bigger problems in the long run. Whether you’re looking to improve efficiency, increase competitiveness, or simply stay ahead of the curve, reducing tech debt is a critical step in the right direction.

👉 So this time we'll give you some practical tips on how you can ensure your products remain high-performing and sustainable in the long term.

If you're like me and learn better by seeing everything in action, there's a chapter in the end about how our team puts these tips into practice.

Let's dive in.

What is technical debt?

Put simply, technical debt (TD) is the cost of reworking software that is difficult to modify or maintain. It usually happens when the development team takes shortcuts in favor of speed of delivery.

Tech debt is a metaphor and an umbrella term for multiple different types of debt. This makes it tricky to define, pinpoint or track. In this article, we’ll primarily discuss how to prevent the most common types: code debt and architectural debt. And for engineers, the tell-tale signs are 1. A change to the software is unusually hard to implement or 2. The code became more complicated after introducing a simple change.

From a developer’s point of view, technical debt is anything you tell yourself you’re going to fix “later.” But more often than not, later never comes.
Artur Hebda Full Stack Engineer

There’s still much confusion and debate about what counts as tech debt. So let’s clear that up. From our perspective, tech debt can’t be boiled down to the number of FIXMEs or TODOs in the codebase – it’s more nuanced than that. It’s also not identical to bugs or badly-written code. Bugs can be caused by tech debt, but TD isn’t limited to bugs. And bad or messy code doesn’t always evolve into tech debt.

Why is it important to reduce tech debt?

Left unchecked, technical debt can have a serious impact on your company’s bottom line.

Like financial debt, TD accrues interest over time. The longer it’s ignored, the more costly it becomes. For example, if an engineering team fails to update dependencies regularly, it can lead to unexpected costs down the road. Why? Because when a library or framework deprecates, the team will have to spend unplanned time repairing or replacing it. Over months and years, unmanaged tech debt erodes the quality and scalability of your product. It can also hinder your ability to hire new devs or rely on documentation.

It’s estimated that software development teams waste about 23-42% of their time dealing with the ramifications of technical debt. This drain on resources typically impacts delivery speed. Timelines often get harder to estimate, product improvements get sidelined, and stakeholders grow uneasy with the lack of progress. Not to mention, developers can quickly get burned out when they are constantly working on issues that could have been avoided.

Types of tech debt

When Wade Cunningham first coined the term technical debt in the 1990s, he was mainly referring to code debt. However, the definition has expanded a lot since then. We can now say there are several different types of tech debt, including:

Architectural debt occurs when we make sub-optimal decisions about the system architecture. For example, you build your web application using a low-code platform (e.g WordPress). But later, when applying user feedback, you realize that your product requires way more customization than the platform can offer.

Code debt. This is the classic definition of tech debt. It refers to the consequences of writing code that is difficult to interpret, update or maintain. The code might be overcomplicated, inconsistent, or contain errors that can result in bugs or other issues.

Infrastructure debt can accumulate when the infrastructure (e.g. servers, databases) supporting a system is not properly maintained or upgraded. This can result in critical performance issues, such as unplanned downtime or the slow loading time of key product features.

Documentation debt occurs when developers fail to document their code correctly. Missing, incomplete, or outdated explanations can cause confusion when coworkers or new team members come in contact with that code. In bigger systems, doc debt can also make it hard for engineers to interpret how certain processes or features actually work, and how parts of the codebase are connected.

Data debt is incurred when software teams don’t properly invest in data management. Failing to break down information silos can cause data duplication or missing data, making it difficult for product teams to properly connect with users.

Security debt builds up when proper security measures are not considered during the software development process. For example, the team delays fixing a known system vulnerability, which increases the likelihood of an SQL injection attack. Unmanaged security debt can lead to major data breaches and other serious violations.

Common tech debt triggers

Business and management causes

Tight deadlines are one of the most common causes of tech debt. When management imposes strict deadlines for software delivery, engineering teams may be forced to take shortcuts (e.g. building a system that’s functional, but not scalable). Whether these shortcuts are intentional or not, organizations should prepare to deal with the consequences later i.e. allocating development resources for refactoring.
Poor communication. If engineers aren’t aware of the project’s goals, priorities, and timelines, they won’t be able to make decisions that are right for the product. Lack of discussion around product architecture or infrastructure design can lead to critical system failures later on.
Lack of planning. Failing to map out the product vision and set achievable goals will almost certainly cause tech debt. When a team lacks direction, they are more likely to choose the wrong approach (e.g inflexible web framework, unreliable hosting provider, etc.) or work on tasks that don’t move the project forward.
Shifting strategy or requirements. Abrupt changes or additions to the project spec can also lead to an accumulation of tech debt. For most agile development teams, however, this is unavoidable. Constant iteration is a natural part of the process.
Scarcity of resources. Understaffed development teams usually don’t have the bandwidth to check edge cases. Most of the time, they still have deadlines to contend with, which can force them to sidestep best practices (i.e. not conducting PR reviews, running automated tests, writing documentation, etc.)

Engineering team causes

Inexperienced engineers often make poor decisions that lead to tech debt. For instance, they are more likely to write duplicate code, making potential bugs harder to find and fix. They can be less likely to follow naming conventions, use proper programming language patterns and structures or properly format their code, making it difficult for other engineers to understand and update it in the future.
Not striving for excellence. When engineers don’t take ownership of their work or care enough about the quality, then the product suffers. Sloppiness can lead to major problems in the codebase that will have to be addressed at some point.
Overengineering. On the other hand, aiming for perfection can also backfire. Complexity for the sake of complexity often causes unnecessary roadblocks. For example, the team switches from a monolithic to a microservices architecture too early, which makes it difficult to apply changes during subsequent iterations.
Mistakes. Everyone makes them – even your senior devs. Sometimes, despite prior research and planning, the right decision doesn’t become clear until after a change has been implemented. This is one of the reasons why tech debt is inevitable.

Intentional vs unintentional tech debt

It’s important to remember that tech debt isn’t always a bad thing. More often than not, it’s an unwelcome burden. Other times, a product actually benefits from taking it on. But regardless of how tech debt is perceived by the team, it can be split into two camps: intentional and unintentional.

Intentional tech debt: The team deliberately incurs tech debt in order to achieve a short-term goal. Typically, this happens early in the product development process when speed to market is a priority (prototyping, MVP building, etc.) But it can also occur when the team is under pressure to release a new update, feature, or meet any kind of tight deadline.
Unintentional tech debt: This can occur as a result of poor design choices, lack of attention to detail, lack of product understanding, and other software development pitfalls. In other words, it’s mostly accidental.

Martin Fowler’s ‘Technical Debt Quadrant’ illustrates the difference between deliberate and inadvertent debt and their reckless and prudent counterparts.

How our team at Railsware reduces tech debt

As the old adage goes, ‘prevention is better than cure.’ Here are some of the things we do to prevent, track, and tackle tech debt.

In-depth planning

Without a product strategy – and a plan on how to execute it – it’s virtually impossible for an engineering team to make the right decisions at every turn. That’s why having a product roadmap is so important.

A roadmap is more than just a list of tasks to be completed. We consider it a living document that displays the actionable items of a product strategy. Features are clearly prioritized, so that team members know where to focus their efforts from the get-go. At a glance, engineers can learn what the project’s main priorities are and grasp how their code informs the bigger picture.

Meanwhile, the product backlog helps teams keep track of tech debt (among other things). Although it’s easier to ignore code smells, there are benefits to properly recording tech debt each time it crops up. The more visible it is, the less chance it has to fester.

So, engineers should create tickets in the backlog each time they spot an inflexibility in the codebase. Then, whenever there are resources to spare, the team can assess the issue’s priority level and start investigating its root cause.

Focusing on what matters

Not all tech debt is created equal. Oftentimes, it doesn’t make sense to refactor a feature that is rarely modified in the first place. Turn your attention to the code that actually matters. Work on strengthening key product architecture and infrastructure elements with each iteration. It’s better to gradually increase the overall agility of your product than constantly tinker with ‘good enough’ code.

At Railsware, we refactor only when there is an urgent and explicit need for it. That way, we don’t sink resources into fixing non-essential things. At the same time, our engineers are encouraged to make minor, incremental improvements whenever they have a chance. They follow the boy scout rule when making those changes: Leave the code better than you found it.

Making sure engineers are heard

Management should always actively seek out and listen to the perspectives of the engineering team. In our view, engineers are best placed to identify potential technical debt before it occurs and suggest ways to avoid it. More often than not, their expertise can be leveraged to create more sustainable and performant solutions.

At Railsware, we promote an open feedback culture, where team members are encouraged to voice their opinions/concerns with their team (and the wider organization where appropriate). Dedicated Slack channels for squads and guilds are useful, but they shouldn’t replace synchronous communication. Management should make time in the day/week/month for well-planned meetings.

For example, daily standups aren’t the only meetings our Coupler.io engineers regularly attend. Many contribute to big-picture discussions, such as:

Bi-weekly Iteration Planning Meetings (IPMs) to discuss upcoming work
Bi-weekly product demos (involves all departments: engineering, marketing, design, etc.)
Product retrospectives once a month
Product strategy meetings with key stakeholders every 2 months

Not all engineers are required (or invited) to attend those meetings. But there are always at least one or two members of the team in attendance. This ensures that strategic decisions are made in collaboration with those who know the software best.

Embracing a flat(ish) organizational structure

Job titles and hierarchies often cause unnecessary blockers for agile development teams. However, we believe that the more autonomy developers have, the more empowered they are to build great products. In fact, adopting elements of a holacratic organizational structure has helped us develop a culture of ownership across all of our processes. In our version of holacracy, individuals within teams and guilds work closely to achieve a common goal, instead of relying exclusively on managers to assign roles and distribute tasks.

For example, our Mailtrap development team self-organizes into specialized guilds during each sprint. The main ones are:

Frontend guild. Several developers work to push the project forward, keep frontend code clean, and introduce new approaches.
Support guild. Here, developers devote their time to improving parts of the system where bugs have been found or tech debt alarms have been raised.
OSS guild: Others work on open-source aspects of the product (public gems, SDKs).
Security guild: This group of developers works on strengthening data security by improving data access processes, managing access to project assets, and so on.

In the context of tech debt prevention, this ‘guild’ approach has a couple of key benefits. Firstly, the team gets dedicated time and resources to make system improvements and address red flags in the codebase. Secondly, team members can work on different various parts of the project over several months. This lets them develop a deeper understanding of the project requirements and better contribute to product decision-making.

Investing time in pair programming

Pair programming refers to when two developers collaborate simultaneously on part of the project’s code. At Railsware, pair work helps us solve problems more efficiently and create smarter, more robust solutions. Sessions can run for as long as 2-3 hours, or as little as half an hour – it all depends on the complexity of the issue at hand. However, regardless of how long these sessions last, we believe the time investment is always worth it. When it comes to preventing tech debt, the primary benefits of pair programming are:

Better quality code. With an extra pair of eyes on the code, it’s harder for mistakes or bad habits to slip through the cracks. Errors, bugs, and bad practices are fixed long before they have a chance to morph into tech debt.
Ability to see the big picture. When engineers work in pairs, they are better equipped to evaluate all sides of a problem and keep the big picture in mind. (For example, the ‘Navigator’ investigates the context, which helps the ‘Driver’ shape the small details of implementation).
Improved knowledge sharing. Team members have more opportunities to bond, share their skills, and develop a shared understanding of the product direction. This helps them to make better day-to-day decisions that support the product’s sustainable growth.

Conducting regular PR reviews

Regular and thorough pull request reviews are a key line of defense against the accumulation of tech debt. The practice enables teams to identify dysfunctional code and other code smells at an early stage.

So, to promote consistency and reliability, it’s important to establish a standard protocol for PR reviews. The more streamlined the process, the easier it will be to identify potential issues, communicate, and resolve them quickly. Here are some of our tips:

Before sending a PR for review, authors should attempt to distance themselves from their code – try to look at it objectively, and within the context of the product. This way, they can correct some clear abnormalities and reduce some of the reviewer’s workload.
For large and complex PRs, authors should create to-do lists in the PR description. Meanwhile, engineers should be proactive and review PRs at least once a day.
Reviewers should ensure comments are clear, actionable, and respectful. See Conventional Comments for some great examples.
When the PR is too big, or unclear, the reviewer should ping the author and do a synchronous pair review.
Automate where possible. Our RoR developers often use Rubocop to maintain code formatting and catch potential issues. Simplecov is also useful for checking code coverage, as is Brakeman for identifying any security issues.
The team should aim to close PRs within 2-3 days, otherwise, a build-up can occur and it’ll be harder to give each one the attention it deserves.
When reviewers identify improvements that don’t directly relate to the purpose of the PR, they should approve it, but leave comments. Point out typos, better variable names or RSpec scenario titles, etc., but keep the project priorities in mind.

Final thoughts

Nobody wants to deal with tech debt. But to prevent it from causing real harm to your product, it’s essential to have a clear understanding of what it is, and how it accumulates. It’s important to make sure that engineers are involved in decision-making processes. Not to mention, giving engineers more autonomy can empower them to take ownership of the technical debt and be more proactive in managing it. Conducting regular code reviews can help teams stay on top of their technical debt and prioritize the most critical issues. Meanwhile, pair programming can also help teams catch issues early on and ensure that code is up to the required standards.

And that's it! I hope this helps you in any way with your teams or just for yourself. Please comment if you have some ✨insights✨ to add!

Oh, and in the original article about technical debt, over at Railsware's blog, there's some more resources on important topics throughout the chapters, so feel free to get lost on knowledge over there

See ya 🤗

What's Mail Merge? [use cases + tutorials]

beacampos — Thu, 27 Jul 2023 10:27:25 +0000

Can you imagine being a VP at a large corporation and reaching out to each of your customers directly? Bankers or insurance associates do it all the time, and somehow, they manage to personalize each of the thousands of messages they send. Are they superhumans? Some might be, but most of them probably just use a good ol’ mail merge feature.

In today’s blog post, we’ll explain mail merge and all the peculiarities associated with it. We’ll also provide tutorials on creating a mail merge in MS Office, Outlook, Google Docs Editors, and Gmail. So, let’s get started!

What is mail merge?

Mail merge is a method of building personalized letters, documents, or emails with a bit of automation. Components of mail merge include:

A template of a letter or an email with specific placeholders in the body, and
A spreadsheet with a set of data that should replace placeholders for each individual recipient. These can be names, addresses, or any other custom data. Some tools even allow for sending individual attachments with emails. A mail merge functionality combines these two components into one piece – a personalized message with data relevant to you and you only.

Mail merge example

Very often, when you receive a letter from a company or an institution, you’ll see your name and address printed on it. It will often start with “Dear John,” unless your name is Suzie, then you’re likely to see “Dear Suzie.” In the body, you’ll find some seemingly personalized references to your actions or further mentions of your personal details. In many languages, you’re likely to see gender-specific expressions.

The same goes for emails. Whenever someone reaches out trying to sell you something, their email will probably look like this:

Another email from this series would look something like this:

And it can go on for thousands of emails sent within just minutes. No one would bother writing each of these emails and inserting details one by one. Instead, they delegate these mundane tasks to mail merge. At the same time, since the emails look fairly personal, they have a higher chance of convincing a recipient to take the desired action.

The data source for such emails would be similar to this:

While the raw text i.e. the template will have the following structure:

What are the use cases for mail merge?

Mail merge has been in use for many years, even before the internet changed how we do many things. It’s omnipresent both in offline and online worlds. Typically, it’s used whenever it’s necessary to combine a form letter with personalized variables.

The most common mail merge use cases include:

Emails – usually used for mailing large recipients lists. With mail merge, you can create an email template and personalize variables by inserting the required information from a data source;
Paper letters – used for snail mail. The contents, designs, and fonts will be the same throughout the letters, while the names, postal addresses, greeting lines, and other variables will be personalized. Once the data is merged, you can print your letters and mail them to the recipients.
Envelopes, print labels, and address labels – similar to paper letters, you can also create a bunch of envelopes, print labels or mailing labels, and address labels with custom data. These are particularly useful if you’re sending packages to your customers.
Directories – used for creating directories, catalogs, or lists of customers. Mail merge allows for combining different types of data sources into a single new document.

Which tools to use for mail merge?

If you’re using Microsoft Word, Excel, Google Sheets, or Google Docs, you can easily send emails from Gmail or Outlook. However, the mail merge process can be a bit limited with direct methods (for example, you can’t add attachments or Cc/Bcc fields). Instead, you can opt for various add-ons that will make your life easier and provide access to more functionalities. Here are the most popular user choices:

GMass – a popular plugin for Google Chrome that comes with mail merge capabilities. And it does much more than that. Not only can you quickly set up personalized emails to your recipients, but you can also schedule them to be sent at a specific time and set up automatic follow-ups to be sent if no reply is received. GMass also allows for tracking opens and clicks, so it makes a pretty decent cold email platform.
Mailmeteor – another popular plugin that offers a chance to personalize emails and send even 2,000 of them in a single day. Like the previous entry, it works with Gmail and comes with email tracking functionality. On top of that, each email can be previewed to avoid any trouble (and trust us, errors do happen).
Mail Merge Toolkit – a Microsoft Office add-in that enhances Outlook, Word, and Publisher with mail merge capabilities. It allows you to send RTF or HTML emails with attachments. At the same time, Mail Merge Toolkit reduces the chances of receiving false responses.
YAMM – not just Yet Another Mail Merge. As the creators claim, it’s “the world’s most popular Google Sheets add-on for Gmail and G Suites users”. It comes with all the features of the other tools, such as email tracking and scheduling. Users can also use mail merge with individual attachments. And there are a bunch of advanced features, such as individual, clickable links, or pre-filled forms.
Easy Mail Merge is also a similar tool that, to no surprise, is used for mail merge in Microsoft Outlook. It comes with a standard set of features for personalizing and scheduling emails. Its users can take advantage of automated scenarios to send personalized messages without any interference.

What’s interesting is that some of the tools we mentioned also offer support for cc and bcc fields. This can prove especially useful for salespeople out there. Frequently, they send mass campaigns to hundreds of leads at the same time. Rarely, though, there’s just one account manager responsible for each of these prospects. With cc/bcc in mail merge, they can add respective managers and/or their team leaders only to specific emails.

Updating the data source we showed earlier:

Mike as a team leader could be bcc’ed on multiple emails (invisible to customers) while the rest of the crew would be split between emails and placed in the cc fields. Each plugin would add the right contacts to the right fields. Awesome, huh?

Most, if not all, platforms for sending mass emails (such as email marketing platforms or transactional email providers) also offer mail merge. They might not refer to this feature with the same name. Instead, you might find references to custom or dynamic fields or even to snippets. Regardless of the naming, it’s all pretty much the same thing. Often, the functionality can also be replicated with various APIs without any trouble.

Should I use a plugin or a platform for mail merge?

The choice of an online tool for mail merge really depends on your use case. If you’re more of a casual sender and don’t send more than 50-100 emails a day, you’ll probably be better off with a simple plugin. This way, you can get everything you need in a simple interface, sometimes even without extra expenses. We introduced some of the Gmail add-ons and Outlook add-ins above, but you can also find tools for other popular email clients.

If you, however, send newsletters, transactional emails, or other forms of mass emails – then you’ll need more than that. Email clients enforce strict limits on sending volume and offer minimal capabilities.

Plus, sending thousands of emails from free email accounts or even Google Workspace will look suspicious to spam filters. These accounts don’t provide access to DNS records, dedicated IPs, or scalable email infrastructure. In other words, you have limited control over your email deliverability.

So, it’s a much better idea to use a dedicated marketing platform or a transactional provider. As mentioned, nearly all of them offer mail-merge-like functionalities to personalize your emails quickly and accurately.

For example, Mailtrap Email Sending has a template feature that operates on the handlebars engine. While it’s not your typical mail merge, its operation is quite similar. The template includes placeholders and the values are called with API. And instead of the Excel spreadsheet, you have a JSON object that stores your data.

Templates are a more reliable and accurate way to personalize your emails. While mail merge is a useful feature, it has a fair share of disadvantages. It lacks customization options and leaves wiggle room for errors. By storing the templates within Email Sending’s platform and referencing them through API, you can stay assured that your emails will be personalized properly. And you’ll also deliver emails right into your recipients’ inboxes. Learn more about handlebars here.

Other features of Email Sending include actionable analytics with drill-down reports, RESTful API and SMTP service, email logs, a sending throughput of up to ~10,000 emails/second, dedicated IPs, auto IP warmup, and suppression lists available to users after a straightforward setup/migration process.

How to create a simple mail merge for emails

Now let’s see how to use mail merge feature in Microsoft Office and Google Docs Editors.

Microsoft Word with Microsoft Excel as a data source

To send bulk personalized emails with mail merge, you’ll need a word processing software i.e. MS Word, MS Excel, and a mailer such as Outlook or Gmail. Keep in mind that you should have Outlook as a default email program to be able to merge to email directly from Word.

1 Open the Word document and create an email template you want to use. Type the body of the message and skip the variable data you want to personalize;

2 Now go to the Mailings tab, click Start Mail Merge, and select Email Messages. Depending on the Word version you’re using, you may see an additional field called Step-by-Step Mail Merge Wizard… You can select this if you prefer a guided setup.

3 Press Select Recipients. Here, you can either create a new list or use an existing one. The mailing list will be your data source. We’ll be using the list of recipients in Excel spreadsheet we referenced earlier, so we’ll choose Use an Existing List… from the dropdown menu.

4 Upload your data source. Choose if you want to upload a particular sheet or an entire workbook. Keep in mind that you should group all your recipients on the same sheet. If you want to, you can also press Edit Recipients List to edit your contacts list. It will open the mail merge recipients dialog box in which you can find duplicates, filter desired recipients, set conditions, or add/remove entries in the source.

5 Now it’s time to insert placeholders in your main document. Press Insert Merge Field. In the dropdown menu, you’ll see the variables you defined in the Excel spreadsheet. You can also use the Match Fields located in the Write & Insert Fields section. That way, you’ll match the merge fields in your current document to the fields in your data source. Once you’re done, you can format the email body the way you want.

The finished email should look something like this:

6 Press Preview Results to see what your merged emails will look like. In case any of the variables are incorrectly defined or don’t exist in the data source, you’ll see an error message during the preview. Click the left and right arrow buttons to look through each email. Press Preview Results again to exit the preview mode and make any necessary changes if needed.

7 When you’re happy with your emails, click Finish & Merge. Choose Merge to Email.

8 Define the To (choose Email to send messages to the recipients in your address list), Subject, and Send as fields. Press Email Merge to Outbox once you’re done.

Within seconds, you’ll find the emails in your Sent folder.

Microsoft Word with Microsoft Outlook contacts as a data source

The mail merge process looks quite similar when you use Outlook contacts as a data source. Yet some parts of mail merge are still different.

The first two steps are similar to what we’ve already described. So, let’s skip them here.

1 Press Select Recipients and click Choose from Outlook Contacts…

2 If you don’t want to email all the contacts, press Filter Recipients and filter your contacts by category or manually. Click OK.

3 Then go ahead and insert merge fields. Make sure the field names you pick exist in the data source.

4 Next, preview your emails, and if everything looks good, hit Finish & Merge and choose Merge to Email the way we did in the previous section.

Note: Older versions of Microsoft Outlook supported mail merge directly. It was possible to select this feature from the UI. However, Microsoft 365 and even Outlook legacy versions no longer have this feature.

For more information on mail merge in Microsoft products, you can refer to Microsoft documentation.

Gmail with Google Sheets as a data source

Google Workspace doesn’t have a native mail merge feature. So, you have three options if you want to enable this feature: use Google Docs or Google Sheets API, an App Script, or an add-on.

Today, we’ll detail how to create a mail merge for Gmail and Google Sheets using the App Script.

Unlike Microsoft 365, you don’t need a word processor to complete the mail merge. Instead, we’ll create a template in Gmail, populate Google Sheets with recipients’ names and addresses, and use App Script project to personalise and send emails.

1 Create a Google spreadsheet and insert the data you want your emails to be personalized with. Or use an existing document/sample provided by Google. If you’re doing mail merge for the first time, we recommend using the sample as it has an App Script project attached to it and a mail merge feature enabled. You can find it here.

Note: If you’re using the sample document and you change the name of the recipient or email sent fields, make sure you update the App Script as well.

2 Click Extensions and then App Script to open the project and make the changes (if any).

3 Go to your Gmail account and create an email draft. Populate the text with accurate placeholders and use double curly braces to separate them from the text. Make sure you use the exact merge field names that you have in your Sheets. Copy the subject line.

4 Go back to your data file i.e. spreadsheet and then click Mail Merge → Send Emails.

5 Authorization window will appear. Click Continue and sign into your Google account.

6 At this point, Google hasn’t verified this app window might appear. Click Advanced → Go to {project name} unsafe and give the G sheet access by clicking Allow.

7 Go back to the spreadsheet and click Mail Merge → Send Emails once again. Mail merge window will pop up, asking you to insert the subject line of the draft we copied earlier. Press Ok.

8 If you did everything correctly, the emails will be sent to the intended recipients. You’ll see the timestamp in the Email Sent field in the Sheets. You’ll also find them in your sent folder.

Keep in mind that you can’t preview your emails before sending them to the recipients. But you can modify the App Script, which gives you more flexibility. Refer to the Google documentation for more details.

You can check out this guide if you want to use mail merge in Google Docs to create a form letter within a single merged document. For a step-by-step tutorial on mail merge in Gmail and Google Editors, read this blog post.

Alternatively, you can install add-ons that will enable you to mail merge directly from Google Docs or Gmail.

Test your mail merge setup with Mailtrap Email Testing

Last but definitely not least – don’t forget to test your mail merge emails before they’re sent to customers.

Why? Well, there is a big chance that you have personally received (probably more than once) an email with a {NAME} placeholder that somehow didn’t fetch the right data.

For salespeople, this could jeopardize a chance of striking a major deal. For others, this could ruin a good first impression and completely distract recipients from a call to action.

The good news is that some platforms/tools that do offer mail merge also offer features for previewing emails before they’re sent. But, if you are a user of a platform/tool that does not, or simply skip the previewing process altogether, then you will only find out if something is wrong with your email when it’s already too late.

So, to prevent such a situation, make sure you use a dedicated tool for testing emails.

Mailtrap Email Testing is a safe environment for testing. It’s another portion of the Mailtrap Email Delivery Platform.

With Email Testing, you can inspect and debug emails in a staging environment without the risk of spamming recipients. It captures all the SMTP traffic within a virtual inbox and leverages a fake SMTP server.

Email Testing is easy to set up with its SMTP credentials, ready-made code snippets, and SDKs for different programming languages. With its help, you can preview your emails to see how various mailbox providers render the HTML content. You can also view tech info with transaction details and header values, check the spam score, and forward emails to real inboxes manually or automatically.

These features will be particularly handy for testing your mail merge emails. That way, you’ll never send ‘Dear {First_name}’ emails to your recipients.

Easy, no? I hope this was helpful

Oh, and if you want to start testing with Email Testing or check out our other guides, visit the Mailtrap blog and leave your feedback in the comments!

How to Pick the Right Product Development Partner

beacampos — Tue, 04 Jul 2023 15:33:18 +0000

Developing a product that relies a lot on software can be quite challenging. As the business landscape keeps changing, organizations seek adaptable methods of management. Among them, outsourcing has proved itself to be a strategic tool that drives change and boosts operational efficiency.

For many, outsourcing is not only a business development tactic. It's also the path for expanding into new markets without having to build or nurture the necessary skills from scratch. Besides, in the big picture, outsourcing acts as a reliable way of creating products and services that are innovative.

But product development consulting goes way beyond the development phase. It should include the broader concept of product management, which guides every stage of the product lifecycle - from development to positioning and pricing. Product management involves not only the technical aspects of developing a product, but also the strategic and customer-centric aspects that dictate the success and market-fit of a product. Therefore, this role combines knowledge from business, technology, and UX that helps make informed decisions. To do this, a product manager employs various techniques and tools to put the product's vision and strategy in place, analyze user needs, manage data, and oversee the team.

So by outsourcing product development services to a trusted product partner, you can tap into their expertise in product management. Choosing the right one is definitely crucial for the success of your product. With their expertise, you'll be able to turn your product vision into reality, ensuring that the output not only meets your expectations and needs, but also solves your users’ problems.

The Outsourcing Dilemma

When you want to introduce a new product to the market, several development options come to play, like building an in-house team, collaborating with another company, or outsourcing the process to third-party experts. While each choice has its pros and cons, outsourcing product development often emerges as the most efficient one. This is most often done by smaller startups since, in the early stages, it’s not profitable to create separate workstations for each production stage.

Outsourcing product development means hiring a team of experts to handle the process's entirety, which becomes a significant advantage if your business lacks the in-house resources or expertise to do the job. But there are many reasons why choosing this option can be wiser, for instance:

Cost and time efficiency: Great product development teams have the tools and resources for quick and efficient execution. With their sole focus on your project, they can be more productive than an in-house team that's juggling many projects that often might seem equally urgent.
Delegated management: Outsourcing frees you from managing the development process, allowing you to tune in on other sides of your business. By involving experienced specialists with relevant experience, you can avoid potential hiring mistakes that many startups make.
Reduced overhead costs: Outsourcing also gets rid of the expenses related to managing the development process in-house, allowing you to allocate resources more efficiently. And, again, not worry about these details at all.
Access to expertise: Since you have access to pros that might not be available otherwise, you'll be closer to the highest quality result. Simply put, don’t forget to stay realistic by trying to understand what’s lacking in your team, and how you can most efficiently make up for it.

On the other hand, outsourcing means transferring control of a vital part of your business to an external group of people. Don’t forget that this is still your product and resources. You must carefully consider all the options available to you and voice your concerns to avoid risks, such as:

Quality control issues: There's always the risk that the company will cut corners to save money or meet deadlines, which could result in an inferior product, damaging your reputation, and costing you in the long run - the so-called technical debt.
Communication challenges: You may find the perfect team to collaborate with in a different country than yours. Naturally, different time zones, language barriers and cultural nuances can cause misunderstandings. A structured and clear communication system can be very helpful if established from the beginning.
Intellectual property issues: These concerns arise because the outsourced company will likely have access to your company's confidential information. If not properly safeguarded, it could fall into the hands of competitors or be used against your interests. In this case, it's good to have contracts, non-disclosure agreements, etc. in place to protect yourself and your business.
Being dependent on one team: After picking your partner, you'll possibly be dependent on them for ongoing support, updates, and maintenance. If the relationship deteriorates or fails to meet expectations, it can impact your product's continuity and future development. Be sure to establish contingency plans, do your research in advance, and communicate your concerns and goals from the get go.

While there are downsides, the benefits of outsourcing can far outweigh the risks. If executed correctly. An experienced and reputable product team can help you bring your vision and new product to market without breaking the bank.

When Outsourcing, Don’t Leave These Out

Finally decided to outsource? You’ve carefully considered its pros and cons but it’s time to choose a trustworthy company. A suitable product development partner should have a clear understanding of your vision and goals, proven track record of success, a commitment to quality, focus on customer service, and offer competitive pricing. Let's see what this means.

Start with a clear vision and goals. This is the first thing to look for. Find a team that not only understands your product and your business but also has the ability to translate that into a successful development process. Spend time explaining your vision and goals in detail. Ask as many questions as you need to ensure the team understands your expectations and is capable enough to challenge your ideas. That’s how you'll know they’re committed to delivering the best possible results.

Establish a proven track record. When entrusting your product development to an external team, you need assurance that they have a good portfolio. Request case studies from previous clients and look at the company's experience and reputation. As mentioned above, ask questions. Ask about their development process, timings, communication style, approaches, and so on. Don’t worry, you don’t need to get technical. But this is your business, so it’s your responsibility to make sure it lands in the right hands.

Focus on quality. You need a team that commits to developing high-quality products and can back that up. Enquire about their quality control and how they manage any problems that arise during the development process. Or even how they approach any, say, speed bumps. What’s the plan when faced with a time crunch? Would they opt for small iterations or sacrifice quality, for instance?

Focus on customer service. Look for a team that is responsive, easy to work with, and willing to go the extra mile for your and your product's benefit. This goes back to your communication system. Don’t neglect the importance of a well established one, especially in case you end up facing changes or problems along the way.

Make a stake in competitive pricing. A good partner knows their worth, yes, but they understand your needs - your resources included. If they believe in your project and trust their abilities, they'll be open to either negotiate or at least communicate their reasoning clearly. Nevertheless, get quotes from several companies before making your final decision. Do your research both to stay realistic and to back up your arguments. When the time comes to hire the super-team, ask about payment terms, schedules, and the company's policies.

Wrapping Up

The process of finding the right product development partner might seem overwhelming. But hiring an expert team to make your product come to life is definitely a rising strategic move that stops many businesses from failing. And help many customers have what they needed all along.

Most of what you need to do is invest time and effort in research - not only on the available companies but also on your own requirements. Like you're doing right now. By knowing what you need, what your business will gain from this and how to avoid any risks, you're halfway to success.

In the end, this is a partnership. All sides win while working for the same goal. Both parties must feel comfortable in this collaboration, so feel free to communicate your concerns, requirements and expectations objectively.

Thanks for reading! Feel free to share your own tips or experience ✌️

End-to-end testing Chrome Extensions (using Playwright)

beacampos — Wed, 22 Feb 2023 14:49:34 +0000

It’s frustrating for users when an extension regularly crashes, freezes, or fails to function as expected. Negative reviews, product abandonment, and ultimately, revenue losses are all situations that developers want to avoid. Not to mention, the process of fixing unstable extensions can be time-consuming and costly. So, it’s vital to ensure that your extension remains stable and reliable after changes have been made. In this article, we’ll explain how to accomplish this via end-to-end testing.

To ensure your extension works properly, it’s essential to test it as closely as possible to how users will interact with it. To do this, we’ll write end-to-end tests using a tool called Playwright.

Here are a few reasons why it’s the right tool for this task:

It supports multiple programming languages like JavaScript, TypeScript, and Python.
It has the ability to intercept and deflect network requests, which is a powerful feature.
It does a great job of automating tests on Chromium, Firefox, and Webkit browsers (but for the sake of brevity, we will only cover Chrome extension testing).

Getting set up

The first step in the process is to set up your testing environment. So, to add Playwright to your project run:

npm init playwright@latest

or see more installation options.

The installer will ask you:

For a location to put tests
To add a GitHub Actions workflow
To install browsers for running tests
After installation, you’ll see example specs and a Playwright config.

Since we’ll only be testing Chrome extensions here, we can remove Firefox and Webkit in Playwright config:

...
projects: [{
  name: "chromium",     
  use: {            
    ...devices["Desktop Chrome"],   
  },    
}],
...

Once you’ve set up Playwright, you’ll be able to launch example tests using the command npx playwright test.

Add extension to Playwright configuration

To test your extension, you’ll need to create a browser context with the extension enabled. This can be done using a helper function that launches a persistent context in Chrome. Here’s an example of what the code might look like:

import { chromium } from "@playwright/test";
import path from "path";

...

export const createBrowserContext = async () => {
  // assuming your extension is built to the 'public' directory 
  const pathToExtension = path.join(__dirname, './public')  
  const userDataDir = '/tmp/test-user-data-dir' 
  const browserContext = await chromium.launchPersistentContext(        
    userDataDir,    
    {   
      headless: false,  
      args: [`--disable-extensions-except=${pathToExtension}`], 
      ignoreDefaultArgs: ['--disable-component-extensions-with-background-pages'],  
    }
)}

Note: By default, Chrome’s headless mode in Playwright does not support Chrome extensions. To overcome this limitation, you can use a workaround like this:

const browserContext = await chromium.launchPersistentContext(
  userDataDir,  
  {     
    headless: false,    
    args: [     
      `--disable-extensions-except=${pathToExtension}`,     
      '--headless=chromium' 
    ],  
    ignoreDefaultArgs: ['--disable-component-extensions-with-background-pages'],
  }
)

For more detail and alternatives around testing Chrome extensions, check out this guide in Playwright docs.

Writing tests

Now, it’s time to write the test. Here’s an example of what the finished product might look like:

import { test, expect } from '@playwright/test'

test.describe('Test some behaviour of page and extension', () => {  
  test('Look for Earth', async () => {      
    const browserContext = await createBrowserContext() 
    const page = await browserContext.newPage() 
    await page.goto('https://www.google.com/')

    const searchCombobox = await page.getByRole('combobox') 
    expect(searchCombobox).toBeVisible()    

    await searchCombobox.fill('planet earth wiki')  
    await page.keyboard.press('Enter');
    await page.getByRole('link', { name: /Earth - Wikipedia/ }).click() 
    await page.waitForURL('https://en.wikipedia.org/wiki/Earth')

    expect(page.getByText('Earth')).toBeVisible()

    browserContext.close()
  })
})

The above code snippet demonstrates a very basic example. So you will probably need to make adjustments (describing the behavior specific to your extension and what it does with web pages). Once you’ve formulated the test, you can run it using the command npx playwright test path/to/file.

If you need to debug your tests, you can use the --debug flag to walk through the test one step at a time.

npx playwright test path/to/file --debug

Running tests in debug mode has its benefits since you can:

Use Chrome DevTools
Manually go through steps at your own pace
Stop execution whenever you want

Here’s what that might look like.

Add Playwright to GitHub CI

If you generated a GitHub workflow during Playwright installation, you can just push it as is and CI will launch Playwright tests. The only caveat is that if you run tests in headful mode, you should do so with XServer running. To do that, change the line launching tests to this:

xvfb-run npx playwright test

Pro tips

Use the “Record” button in debug mode to effortlessly generate the skeleton of your test. Start by clicking “Record” and then click all the elements you need on the page. This will improve your productivity in writing tests, since you will get all the selectors you need upfront, and will need to make fewer corrections. Check our quick demo here.
As much as possible, use selectors that resemble how users will interact with your code (e.g. getByRole is better than getByTestId since users can’t see testId, but they can see button or input and its labels). Check out this doc for a good example of selectors’ priority in docs of react-testing-library.
Browse Playwright documentation to gain a more thorough understanding of the tool’s capabilities. We’ve only covered the basics here.

Wrapping up

End-to-end testing is the best way to prevent bugs and instabilities from showing up in your extensions. Taking a methodical approach to writing and debugging tests will help you minimize mistakes and improve the reliability of your solution. Meanwhile, robust tools like Playwright take the hassle out of test automation and test environment setup. With the above knowledge, you can be confident that your extensions will continue to provide a smooth user experience even after changes are made.

Thanks for reading! 🎉 I'll leave the original article here if you want to watch the demo videos on how to conduct end-to-end tests on Chrome extensions using Playwright.

SaaS Product Management, The Handbook

beacampos — Tue, 14 Feb 2023 12:11:12 +0000

This is a guide for startup founders and aspiring product managers who want to better understand the role of product managers (PDMs) in SaaS. Keep this guide close to your chest and wait for the light at the end of the tunnel 💡

👉 We'll explain the key functions, skills, and responsibilities of PDMs, common product management concepts, and what to look out for during the hiring process.

What is SaaS product management?

Software as a service (SaaS) product management is the end-to-end process of planning, developing, and scaling software products that are delivered to customers as a service over the internet, rather than as a one-time purchase.

SaaS product managers work closely with engineering, design, marketing, and analytics teams to guide a product through its entire lifecycle. However, unlike project managers, they aren’t responsible for coordinating day-to-day product development activities. Instead, they will focus on shaping the product vision, designing a strategic plan, communicating the value proposition, and monitoring product health.

SaaS vs non-SaaS product management

There are some key differences between the workloads and approaches of SaaS product managers and traditional software or hardware product managers. First of all, the latter typically have to grapple with wider development scope. If we compare a product like Fitbit to Strava, then it’s fair to say that Fitbit PDMs have a bit more on their plates; they must deliver a sleek and highly-functional physical product to users, as well as a full-featured fitness app.

Secondly, SaaS product managers are more likely to leverage agile methodologies (e.g. the Lean Startup model or Scrum) since continuous delivery is standard practice in this domain. SaaS software is typically updated as soon as there is a change. Meanwhile, updates to classic software are less regular. Changes are usually bundled into a major or minor version update.

It’s also tricky and time-consuming to iterate on a hardware product. Updates take much longer to be rolled out, as there are more moving parts to consider; certain malfunctions can’t be fixed with a software patch.

Now, let’s dive into the skills that SaaS product managers need to succeed in this career…

Key skills for SaaS product managers

Leadership

Product managers are natural leaders. They trust the expertise of their team/peers, drive positive change within the organization, and inspire others to do their best and lead by example. They should be willing to delegate responsibility, get hands-on when appropriate, and prioritize shared success over personal gain.

T-shaped

It’s not enough to be skilled at managing processes and people. Product managers should be proficient in one discipline (data analysis, for instance), yet capable of contributing to activities in other departments. For example, they can create rudimentary product designs in Figma, participate in marketing ideation sessions, navigate AWS payment infrastructure, write spreadsheet formulas to analyze data, or even write basic code. Having a robust set of technical and soft skills – and being a fast learner – are highly desirable traits.

Analytical thinking

As analytical thinkers, SaaS product managers constantly use data for decision-making. They like to think outside the box and aren’t afraid to challenge their own ideas or those of others. They can also analyze a problem from multiple angles i.e. SaaS PDMs should be able to put themselves in customers’ or stakeholders’ shoes, and spot relationships between seemingly unrelated issues.

Complex problem-solving

SaaS product managers use a combination of data, research, team input, and experience to develop innovative solutions. They are good at breaking down problems into smaller pieces and creating a step-by-step plan on how to investigate and solve them. They’re also open to adapting their plans in response to new information they encounter along the way.

Decision-making

SaaS Product managers must be strong decision-makers since oftentimes, the buck stops with them. They must be able to make time-critical decisions even when they only have limited information at hand. Regarding high-level decision-making, product managers shouldn’t be afraid to leverage frameworks to dive deeper into the context, invite feedback from stakeholders/knowledge-holders, develop solution variations, and prioritize them.

SaaS Product Manager responsibilities

Here are some of a SaaS product manager’s core responsibilities…

Shaping the product vision and strategy

Product managers are tasked with determining the product vision. They accomplish this by running product discovery sessions, consulting with subject matter experts, utilizing agile startup frameworks (such as Lean Startup or Product-Market Fit), performing competitive analyses, and conducting market and customer research.

Once the vision has been defined, SaaS PDMs are charged with crafting a product strategy that takes it from concept to reality. In addition to building a product roadmap that supports the initial phases of product development, they will also develop a strategic plan for future growth (more on that later). So, it goes without saying that product managers are responsible for aligning all departments to the product vision and communicating it to stakeholders. They will also be tasked with modifying the vision and/or strategy throughout the product lifecycle.

Collaborating with cross-functional teams

Essentially, product managers are the glue that binds cross-functional teams together. On any given week, they will liaise with several members of the engineering, marketing, design, or data analytics departments to share expertise, answer tricky questions, communicate the product strategy, and help investigate or resolve any issues that have cropped up.

"At Railsware, product managers are sort of like spiders at the center of a product ‘web.’ They collect information from all corners of that web — engineering, marketing, design — and use those insights to shape the product vision, design new features, or solve complex problems."

Sergiy Korolov, Managing Director

For instance, when we're working on a product website redesign, the product manager will coordinate efforts between departments to ensure a cohesive end result. They may collaborate with software engineers to create user stories, with designers to tweak UX flows, and with marketing experts to develop a content strategy.

Conducting customer research and user testing

SaaS product managers are responsible for conducting in-depth market research and coordinating user testing. They will gather information on market trends, carry out competitive analyses, and study customer behavior.

Armed with that knowledge, SaaS product managers may run ideation sessions, design user surveys, build buyer personas, or prepare materials for customer development interviews. They will also take the lead in those interviews, and ensure that all research/test findings (cust dev or otherwise) are carefully recorded and synthesized.

Identifying and creating opportunities

A core aspect of the SaaS product manager role is identifying areas for product improvement and growth. They should keep an eye on industry trends and evaluate which ones are worth implementing (for instance, whether or not it makes sense to integrate AI into the product). Whether it’s by running additional product discovery sessions or analyzing the activities of competitors, product managers should constantly seek out new ways to add value to the product and attract new customers.

Now that we’ve explained the intricacies of the role, let’s dig deeper into some of SaaS product management’s most crucial concepts and processes…

Understanding the product lifecycle stages

The product lifecycle can be defined as a series of consecutive stages that the product moves through, from inception to eventual decline. It’s an important concept in product management because the manager role typically evolves in tandem with the product’s journey through the cycle.

The traditional view of the lifecycle has four stages: Introduction, Growth, Maturity, and Decline. However, we’ve adapted the cycle length based on our own experience in product building. It goes something like this:

New Product Development is when the product goes through the conceptual and testing stages: ideation, development, and validation.
Introduction is when the product is launched on the market.
Growth is when the product establishes its market position and brings profits.
Maturity or Stabilization is when the product stabilizes on the market and has the highest sales volumes.
Decline is when the product reaches the extent of its growth and begins to fail.
Afterlife is what happens after the product dies. There are a few different scenarios – it can immediately die, inspire a new product idea, or simply become a relic.

Here’s a visualization of the lifecycle:

What to remember about the product lifecycle

The lifecycle is simply a guideline and not a guaranteed forecast. There is no predicting when your product will pass through the growth, maturity, decline stages – for some SaaS companies, it could all happen within a year of product launch; for others, it could take decades. On the other hand, many products die right after introduction. Therefore, product managers must proceed with caution when making decisions or forecasts based on the product’s position in the cycle.
The early stages are the most important. Namely, New Product Development and Introduction. Of course, when your product is built on a solid foundation, it’s more likely to withstand any challenges that come its way. Spend adequate time testing and iterating on your solution; listen to customer feedback and prioritize new features. Rushing to market with an unvalidated product idea could prevent you from ever reaching the growth stage.

"Don’t underestimate the importance of marketing throughout the product lifecycle. And don’t wait until the later stages to get going. Start making preparations while you are building your MVP; work with the marketing team to create a strategy. These small efforts will pay off in the long run."

Oleksii Ianchuk, Product Lead

There is no such thing as infinite growth. Every product will reach the limits of success at some point, and enter a period of decline. However, this is where product managers can work their magic. They are responsible for creating a new value proposition and finding innovative ways to pivot.
Countless external factors can affect the product lifecycle. Be it new scientific discoveries, natural disasters, economic instability, or political unrest – there are numerous external factors that can disrupt a smooth lifecycle. Sure, these things are out of a product manager’s control. But you still need to be aware of the unwanted impact they can have on your SaaS company in general.

Leadership in product management

In product management, there’s more to being a leader than simply defining tasks, delegating them, and overseeing their execution. In our view, it’s all about finding the balance between authority, responsibility, and accountability. So, what do we mean by that?

Let’s start with a brief explanation of each term:

Authority is about making decisions, telling people what has to be done, and clearly defining the task that is assigned.
Responsibility refers to the obligation to perform assigned tasks.
Accountability is accepting responsibility (in relation to job completion) and taking personal answerability for results.

An imbalance between these three interrelated components can lead to serious communication problems and mistrust within teams. For instance, if a product manager has a lot of authority but little accountability, then they probably micromanage and don’t have the respect of their teammates. If a PDM has lots of responsibility but rarely exerts authority, then they probably struggle to delegate tasks and prioritize their own workload.

To help strike this balance, we take a couple of different approaches: horizontal processes (holacracy) and an adapted RASCI model (RatSClur).

In a nutshell, holacracy is a type of flat organization where teams self-organize instead of relying on orders from managers. Authority and decision-making power are distributed amongst the team, and there are no fixed roles. At Railsware, roles are taken rather than assigned.

Meanwhile, RatSClur is a framework for defining those roles. It helps us keep track of who’s responsible for what across various projects. Here’s a breakdown of what the roles mean and where product managers fit in:

Now, here’s how authority, responsibility, and accountability tie in with each role:

Both RAtSCIur and Holacracy create systems that distribute authority, and empower team members to make decisions for themselves. Thus, product managers aren’t shouldered with all the responsibility for the execution of a project.

A key takeaway here is that good leadership is also tied to healthy communication. So when it comes to cooperating with developers, designers, marketers, knowledge holders, and internal stakeholders, we’ve got a few tips:

Set up a clear goal. Meetings without a goal are bound to be unproductive. Before any call, ask yourself: what is your main message? Set aside time for small talk, but quickly get to the point – and stick to it.
Have a plan. Always come to meetings prepared. Do your homework, gather the materials you will need in advance, and clearly communicate what you need from your colleague.
Remember the audience. Speak the language of your audience. You will need to present the information differently depending on who you are meeting with (marketers, designers, finance experts, etc.) For instance, finance experts might want to know the costs.
Doze the information. Don’t overload your colleague with tons of unnecessary information. It’s totally fine to vent (in moderation). But if you’re unhappy with something, provide others with the information they need to help you.
Respect others’ time. Don’t waste your coworkers’ time by scheduling unnecessary or overlong meetings. Always check whether a face-to-face meeting is really needed; oftentimes, a Slack message will do. At the end of the day, small choices like these can save everyone a lot of time.

Decision-making in SaaS product management

As we mentioned, SaaS product managers are the primary (but not exclusive) decision-makers within the cross-functional product team.

They make day-to-day decisions through a combination of data analysis, research of potential solutions, and knowledge of the product and industry best practices. Sometimes, there is no ‘right’ decision. For instance, when it comes to choosing a new feature to implement, there might not be an obvious candidate in your roadmap. As a PDM, you must make an educated guess based your knowledge of what’s best for the product.

However, major decisions aren’t made in a vacuum. Our product managers leverage decision-making frameworks, such as BRIDGeS (more on that later), to explore the context and brainstorm solutions with other product experts.

Similarly, product strategy decisions are typically made in conjunction with 3-10 c-suite executives and other stakeholders (product directors, marketing leads, senior data analysts, etc.) The frequency of these meetings depends on where we are in the product lifecycle. At the growth stage, once a month. At the maturity stage, once or twice a year.

How to make data-driven decisions and track product performance

Throughout the product lifecycle, SaaS product managers will use product analytics dashboards to track revenue metrics, catch fluctuations in user behavior, identify bugs or bottlenecks in user flows, and pinpoint areas for improvement. Some examples of dashboards are product funnel, customer service, or cohort analysis report.

Put simply, product dashboards allow SaaS PDMs to track product performance and make data-driven decisions on the fly. To make the most of them, product managers should review the dashboards once or twice a week. Our PDMs typically dedicate about one hour per week to this task.

Now, product managers are responsible for choosing the metrics that dashboards are built on. Since B2B SaaS products differ in more ways than one (different business domains, feature sets, audiences, subscription models, etc.), it’s important for PDMs to create custom dashboards that are tailored to the product. This will ensure that decisions are made using only the most pertinent data.

We often use the AARRR framework as a guideline when creating the initial product dashboard for a new product. The acronym stands for Acquisition/Awareness, Activation, Retention, Referral, and Revenue.

When paired with relevant metrics, this framework helps our product managers get a coherent picture of how well the product is performing on the market. Among other things, it allows them to pinpoint and investigate holes in the conversion funnel e.g why are so few users activating their accounts? How can we change that?

In addition to AARRR metrics, here are some of the most common metrics that feature on SaaS product management dashboards.

North Star: The metric that is most indicative of product success. It might be any of the below, but it is usually a financial or user engagement metric.
Monthly recurring revenue (MRR): The predictable total revenue generated by all active subscriptions in a particular month.
Annual recurring revenue (ARR): The predictable total revenue generated by all active subscriptions over the course of a year.
Customer acquisition cost (CAC): How much it costs to acquire a new customer.
Customer lifetime value (LTV): Total revenue generated by a single customer throughout the time that they used your product.
NPS (Net promoter score): Measures user satisfaction; how much users are willing to promote your product to others.
Churn. Defines users who abandoned the product or canceled their subscription.
Active users per day (DAU) or month (MAU). Tells you whether or not users are actively engaging with your product at a sustainable rate. Bear in mind, ‘active user’ is defined differently for each product.
Stickiness of DAU/MAU ratio. When daily active users are divided by monthly active users, you can find out whether or not your user base is growing and what this means for your product in the long term.

What is the balance between data-driven and vision-based product development?

There’s no denying that data has an essential part to play in product development. After all, it’s practically impossible to track SaaS product performance and achieve a product-market fit without it. But in the race to become data-driven, product managers shouldn’t forget about the importance of vision. In fact, they should know that the two are inextricably tied. A product vision is shaped by data, and without a vision, data is useless.

The folks at ProductPlan have identified 5 common pitfalls of data-driven SaaS product management, which we'd agree with. The risks are:

Exclusive focus on the ‘north star’ metric, which leads to missed information.
Too much focus on data leads to analysis paralysis.
Cognitive bias can lead to missed insights or incorrect conclusions.
Not collecting enough data can lead to decisions that come too late.
Misinterpreted data can lead to misguided conclusions.

One of the ways our product managers avoid these pitfalls is by cross-checking the vision with data, and vice versa. When we (at Railsware) first launched our product, Smart Checklist for Jira, we had big ambitions for its future growth e.g. adding templates, a progress bar, custom statuses, and much more. Our vision was to become the top checklist add-on in the Atlassian marketplace.

But to get there, we knew we had to start small and take a data-driven approach to product evolution. To this day, every new feature or functionality we implement is backed by data i.e. what we glean from customer support requests, cust dev, user engagement stats, and competitor analyses. But those features/functionalities are also supported and shaped by the product vision.

Key approaches and frameworks for SaaS product management

The following concepts and frameworks count as some of our organization’s key approaches to product development and operations management.

Building a product roadmap

As discussed earlier, strategic planning is one of a product manager’s main responsibilities. Roadmapping goes hand-in-hand with both short- and long-term planning. Product roadmaps help PDMs set achievable goals, conserve limited resources, and share information with the development team and other stakeholders. More than just a list of tasks, the roadmap is a high-level plan that displays the workflow and milestones of a strategy-based pipeline.

Some roadmaps are feature-oriented, some are time-boxed, and others are based on quarterly objectives. Here’s just one example of a roadmap that is goal-oriented:

Your choice of roadmap will depend on your market niche, product maturity, and development timeline.

Prioritize the feature list and product backlog

One of the biggest challenges when building a roadmap is deciding what features make the cut. But virtually every highly-successful SaaS business – Github, Slack, Trello – got where they are today by prioritizing new features. Instead of wasting time and money on developing non-essential things, they filled their roadmaps with features that would add genuine value to the product.

MoSCoW is one of the most commonly used frameworks for SaaS feature prioritization. Let’s break down how it can be applied to the product backlog when building a roadmap. Firstly, MoSCoW is an acronym for Must-have, Should-have, Could-have, and Won’t-have. Each of these terms denotes a level of priority from highest to lowest.

Must-haves are top-priority requirements. These are features that are essential to product functionality. If we take Uber as an example here, then their ‘route mapping’ feature counts as a must-have.
Should-haves are requirements of secondary priority. These are features that are considered important, but not crucial e.g. being able to pay via a corporate account in Uber.
Could-haves are tweaks that can wait until later in the development timeline for implementation e.g. a tip jar function in Uber’s passenger app.
Won’t-haves (this time) are features that you still want, but can’t actually afford under your current budget or deadline. An example might be Uber’s ride-scheduling feature, which wouldn’t have been essential when the app first launched.

Minimum viable product

In case you haven’t heard of this agile product development concept, the minimum viable product (MVP) is a version of your product that contains the fewest features necessary for release to market. A core component of the Lean Startup Model, the MVP allows startups to create a functional product at minimal cost so that they can quickly gather customer feedback and make valuable iterations. We can personally attest to its efficacy, because every one of our full-featured products – Mailtrap, Coupler, and aforementioned Smart Checklist – began as an MVP.

We’ve written extensively about this concept at Railsware. To get familiar with the in and outs of the MVP — and why it’s so important in practice — we recommend reading this piece on MVP misconceptions before diving into how to build an MVP.

BRIDGeS framework

BRIDGeS is a decision-making and idea-generation framework designed by Railsware. It allows professionals to analyze a problem from various angles, develop targeted solutions, and make a conclusive decision. Sessions can be run either in person (using sticky notes and colored markers) or online with virtual whiteboards (here's the free Figma template for you to try it). It takes about 2-8 people to run a productive session. Depending on the issue at hand, attendees may include a product manager and other stakeholders such as software engineers, product designers, marketers, etc.

BRIDGeS is an acronym for Benefits, Risks, Issues, Domain Knowledge, Goals, and Solutions. Benefits are what you will gain from a future solution, Issues are your existing problems, Risks are potential issues you might face, Domain Knowledge is information that helps provide context, and Goals are what you hope to get from the future solution. Each type can be added to the board using a different colored card.

Here’s an example of what the Problem Space looks like after a problem has been broken down using these descriptors. We’ve used the Uber example again here.

In this example, each task has already been prioritized using the MoSCoW method we discussed earlier. So, it is time to move into the Solution Space. This is where we ideate solution variations based on the identified benefits, risks, and issues. We then describe the chosen solution through epics and nested tasks, which can actually be transformed into a product roadmap.

Lean Canvas

Designed by Ash Maurya, Lean Canvas is a tool for checking the viability of your product idea. It’s considered an alternative to the traditional business plan, and an adaptation of the Business Model Canvas (the brainchild of Alexander Osterwalder).

The purpose of Lean Canvas is to help product managers and startup founders analyze the strengths and weaknesses of their business model, and mitigate the risks associated with launching a new product into a competitive and fast-changing market. However, for existing and well-established businesses, the Business Model Canvas is generally the preferred choice.

In practical terms, Lean Canvas is a single-page document that consists of 9 boxes to be filled in. Their headings are Customer Segments, Problem, Revenue Streams, Solution, Unique Value Proposition, Channels, Key Metrics, Cost Structure, and Unfair Advantage.

Each section allows you to focus on a different aspect of your product offering and structure, to ensure all bases are covered and the spotlight remains on customer needs.
Here’s a short video guide (with Uber as an example) on how to fill in the Lean Canvas, step by step.

Value Proposition Canvas

Created by Strategyzer, Value Proposition Canvas is a tool to help product managers and startup founders get closer to a product-market fit. It can help you understand your customers’ needs and pains, find new ways to drive user engagement, and refine your brand messaging and marketing strategy.

The canvas is divided into two parts; traditionally, a square on the left (Value Proposition segment) and a circle on the right (Customer segment). Here’s a visualization:

When filling out the canvas, you begin in the customer segment, by listing the customer jobs, pains, and gains. This part helps you define the tasks customers are expected to execute, as well as any negative or positive experiences they might have while doing them. Then you move on to the left side, where you will deal with the product. Here you will break down products and services, pain relievers, and gain creators related to your product offering. Essentially, these are the benefits (or unique value) that your solution offers to customers.

After completing the canvas, you should have a strong idea of how to differentiate your product from others on the market and communicate that unique value to your target audience.

Software that helps manage SaaS products

Here are some applications and tools that our product managers use to plan new projects, manage their daily workloads, collaborate with teammates, and connect with customers:

Figma – for collaborating with designers, wireframing, creating interactive prototypes, and sketching ideas/brainstorming.

Slack - for seamless communication with teammates and stakeholders.

Google Sheets – for product planning activities and organizing market research/customer data.

Looker Studio – for creating free product dashboards and visualizing different aspects of product performance (customer success, ad campaigns, sales leads).

Coupler.io – for automating data flows between apps such as Airtable or Pipedrive and destinations like GSheets, Big Query, Microsoft Excel.

Notion or Coda – for knowledge storing, project management and note taking during collaborations.

Typeform – for creating engaging customer surveys.

Google Meets and Calendly – for client calls, conducting customer interviews, and meetings with C-suite executives.

Now let’s dive into something a little different. This next part is for startup founders who are ready to hire a product manager for their team…

How to hire a good product manager

Here we’ll share our process for hiring product managers who are hands-on, t-shaped, and lead by example. So, in addition to all of the key skills we discussed earlier, there are several others we look for during the candidate screening and selection process.

Strong communication skills are a must, of course, since product managers will be working closely with people from all corners of the product and company. As are strong organizational skills, since the role involves juggling meetings, research, leadership duties, and so on. Meanwhile, being attentive to details, curious about how the product works, and having a good memory are also highly desirable traits, though not always dealbreakers.

Here are a couple of other things we take into consideration:

Technical background. In our experience, product managers with technical backgrounds (think computer science or data analysis) are better equipped for the role than those with experience strictly in product design, sales, or marketing. Knowing how to code, how to break down/organize data, and how to spot bottlenecks in development pipelines are highly-coveted skills.

Real-world experience. We aren’t really interested in management degrees. Instead, we strive to hire PDMs who have experience managing real-world products, preferably in the SaaS space. They must be able to critically discuss their past experiences and demonstrate a history of problem-solving, decision-making, and true leadership.

Railsware’s product manager hiring process
Following application screening and candidate selection, our hiring process usually has four core stages: Intro Call, Test Task, Pair Collaboration, and Half Day. Each stage presents the candidate with a new set of challenges and offers an insight into day-to-day life at Railsware.
Check them out on the original article.

This is just one example of how you can structure your hiring process to test for both hard and soft product management skills. For more on how to shape the process, check out this piece by First Round Review.

Resources for product managers

There are no shortcuts to launching a career in product management or becoming an expert in the field. No single resource — book, course, podcast — can teach you everything you need to know about the discipline. However, based on recommendations from our product managers, here are some useful materials to help you grasp the essentials.

Books

The Lean Startup

Already a modern classic, The Lean Startup by Eric Ries is a must-read for product managers working in the SaaS space. It covers the MVP concept in depth and explains how to leverage the ever-popular Lean Startup framework.

INSPIRED: How to Create Tech Products Customers Love

INSPIRED goes much deeper into some of the topics we’ve covered here, including the skills product managers need, and what processes they should follow. It’s suitable for PDMs working at all stages of the product lifecycle, from introduction to maturity and beyond.

The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you

Despite its odd name, The Mom Test is considered one of the top manuals on how to effectively validate your business idea. It explains how to go about the customer development process the right way, and extract meaningful insights from your target audience.

A note on mentorship
"If you’re a software engineer, data analyst, or QA and you’re interested in becoming a product manager, the best advice I can give is to find a mentor. Contact a PDM within your current company who is an expert at their craft, set up a meeting, and see if they can help you evaluate the best path forward. This is a great way to find out if the role is really for you."

Yevgen Tsvetukhin, Product Manager

Podcasts

If podcasts are your thing, then we recommend listening to episodes on a variety of topics in order to gather a balanced range of insights. For instance, instead of listening to just a few popular podcasts on product management – such as Masters of Scale, Product Thinking, or Mind the Product – it’s better to pick 4 or 5 on topics like SaaS product development, marketing, design, and ‘how stuff works.’ For specific recommendations, check out this curated list of the best podcasts for product managers.

Wrapping up

On a closing note, we asked a couple of our product managers what their favorite and least favorite parts of the job are. Here’s what they had to say:

"Experimenting is the most exciting part of SaaS product development. By making small changes to the product and properly measuring the results, you can test lots of hypotheses in a real-life environment. On the other hand, the hardest part is having to make unbiased decisions. You don’t always have tons of data to support your position, and you are dealing with stakeholders who, as all humans, have their personal preferences."
Julia Romanenkova, Product Lead

"For me, the most rewarding part of product management is getting to see how your product benefits customers. However, the hardest part is all of the work that comes after the product launch, and before its success. It takes more than an MVP to start seeing that impact."
Julia Ryzhkova, Product Lead

Product managers are strategists. Not only do they create data-driven action plans, but they bring structure to a founder’s vision, and unity to the contributions of cross-functional teams. In our view, every SaaS company needs designated experts who can answer tough questions and steer a new product along the path to success.

Resources: the original article has extra resources that explain some topics in depth. I'll leave them here for your ✨future endeavours✨
👉 How to market a new product
👉 How to Create a Product Dashboard
👉 Balancing authority, responsibility, and accountability
👉 How to make communication more effective: Proven techniques from a Product Manager
👉 A Full Guide on Startup Metrics for Product Success
👉 How to Prioritize Product Features
👉 Approaching decision-making
👉 T-shaped Skills in Product Development

Thanks for reading!
If you're an experienced PM or startup founder, comment what you struggle with the most on your day to day! Let's figure this out together 🚀

Discovering Product Discovery

beacampos — Thu, 02 Feb 2023 14:54:58 +0000

Validate an idea. Check if there’s a market for it. Ship and listen to users. Iterate. Ship again. Listen to what they say. Iterate.

Heard that before?

Product Discovery, often referred to as Customer Discovery, is hardly a new idea. Despite that, many companies often forget about it or do it plain wrong. This applies to giant corporations, tiny bootstrapping startups, and anyone in between.

What is Product Discovery and why do products fail?

Product Discovery is the process of testing a concept with customers. The goal is, of course, to build the right product. By right, I mean the one that solves real problems, is well-timed and is possible to build with existing technology and available resources.

Sure, that’s easier said than done. But, if the product discovery is done right, it might make the difference between success and failure.

Yet many companies don’t do it right.

In a frenzy to outcompete their opponents, companies ship new features over and over again. The dust hardly settles after the last major launch, before the two other teams are already beta testing new concepts. All that to keep their market position or outpace their biggest rivals.

Many aspiring entrepreneurs also target that tiny chunk of the market. They’re hoping users will jump to their product right away and will grant them eternal glory in Silicon Valley.

To no surprise, many of these products collapse and the list of the most notable failures goes on and on. Let’s mention only a few of them:

Windows Millenium
Apple Newton
Google+
Ford Edsel
HP TouchPad
The New Coke

Each of these companies had a virtually unlimited budget. They could have spent hundreds of millions of dollars on marketing them. They could have hired the world’s top talents to build and sell them. They did.

And yet, each of these products is considered a spectacular failure. Because, whilst they were great in their own way, the customers didn’t really need them.

They gave them a try, some lined up in front of stores for hours. A few even emailed or tweeted friends about them (except maybe for the Ford fanbase in the ‘50s but we can understand that).

Yet, none of the above products really took off, and each was, sooner or later, shut down. These companies still remain some of the world’s biggest and most successful despite these failures. Can’t say the same about thousands of startup founders who lost all their savings (and likely several years of their lives) building failed products.

Product Discovery vs Product Delivery

Product Discovery in agile methodology is often confused with Product Delivery. Despite the name similarity, it’s important to note that these are two completely different processes. They should both be a part of the process that leads to shipping a product, but you shouldn’t mix them up.

Product Discovery, as stated above, is about understanding what kind of solution is needed. It’s about understanding clients and their needs. It’s also about addressing their pains and creating value for them.

Product Delivery, on the other hand, is about building the solution figured out in the discovery process, with scrum methodology for example. It’s about bringing it to clients, seeing their reaction and building on it with future releases.

To make it even clearer, Product Discovery is about building the right thing, whilst Product Delivery is about building the thing right. Simple, right?

Now that we have the WHY part covered, and covered a bit of WHAT too, let’s move on to WHEN.

When to do product discovery? What is continuous discovery?

A very reasonable approach is to begin with proper product discovery, starting very early. It should happen before you even write the first line of code or attempt to sell anything.

Retreat with the team for a few days, relax, brainstorm and generate tons of ideas. Come back, put them in place and see what users think.

Now, likely the feedback won’t be all so positive and you won’t get a perfect hit at the first discovery session. Users won’t be so crazy about the product and user acquisition will be harder than expected. Clients won’t use a feature you thought would be crucial, or that feature will get lost in the process.

That’s why continuous product discovery should be a part of your delivery process. This doesn’t mean weekly retreats with the team (however nice these sound). It’s not about going through the whole process over and over again. This means:

Craving user feedback. It’s about reading app reviews and analyzing support tickets. It’s about harvesting as many feedback sources as you can to understand your users’ point of view.
Testing how users use your product, where they get lost, and what the bottlenecks are.
Reaching out to users, asking for their opinion, and trying to figure out what the problems they’re struggling with are.

Such a process is often referred to as Dual-Track Agile. It’s about discovery and delivery processes that constantly overlap. The example below shows a possible flow:

The discovery session leaves you with several key hypotheses and an idea of a model you could test with users.
During the delivery, the concept is built and given to users. The first downloads happen and users are onboarded.
Users didn’t like the concept but gave some valuable feedback. The concept goes back to the discovery table.
A new concept is designed, under different assumptions. It’s passed to the delivery team for development.
The second iteration is ready and is given to users. More downloads happen than last time and higher user engagement is visible. It looks promising.
It turns out that users were eager to sign up, but didn’t find any value in logging in after that. Back to the discovery.

(many iterations later in a galaxy far far away…)

The delivery team shipped the new concept and it finally seems to be the right match! Growth is significant, users keep coming back. There’s an interest in premium features. Now it’s onto the delivery team to keep improving the product while keeping the discovery team involved at all times.

Continuous Discovery is a bit easier than the initial product discovery. You (hopefully) already have some clients who can help you validate some hypotheses. The more users you ask, likely the better outcome you will get and the more informed decisions you’ll make. Assuming you’ll know how to interpret their answers.

We now have the WHEN part explained so let’s move to the core of this article – HOW to do a proper product discovery.

Product Discovery – questions to ask yourself

Whichever discovery method you choose, there are several product discovery questions worth asking yourself. They will also help you visualize what you want to get out of the process.

Will the customer use this feature? Will they be willing to pay for it?
Will it bring any value to them? Will they feel a difference if you take it away?
Will they know how to use it?
Are we capable of building it? Do we have the right skills, experience, and budget?
Is it aligned with our business goals?

These are not simple questions and you might not know the answers. At first, you’ll probably do a lot of guessing and you’ll get some answers wrong. But over time, once you get to know your users better and test some assumptions on them, it will become clear if your approach is the right one.

If you already have some early adopters, a great method of getting the questions right is by exposing the team to your users.

Many companies ask non-customer focused employees (developers, designers, product managers, etc.) to spend a bit of time with clients. They answer their support tickets, respond to forum posts, jump on calls.

Even a few hours a month can do miracles. This can point you to an approach that wouldn’t cross your mind even on the best-facilitated product discovery session.

Product Discovery techniques

Over the years, many Product Discovery techniques have been proposed. Some gained little popularity, others became omnipresent on product discovery sessions. The most common methods you’ll encounter are:

Design Thinking
Jobs to be Done
OKRs (Objectives and Key Results)
RAT (Riskiest Assumptions Test)
BRIDGeS Let’s cover them one by one.

Design Thinking

Design Thinking is often defined as “a way of solving problems through creativity”. This doesn’t only help with product discovery which we’re discussing in this article. It can also have a very broad usage.

It can help students figure out a good approach to a graduation project. It can be a good way for an NGO to plan a marketing campaign to find donors. It can be also used by any CEO to allocate team members into teams and maximizing the positives.

Design thinking has become a universal approach to solving any kind of problem.

IDEO is widely considered to be the inventor of this approach but they deny such an achievement. Instead, they claim to have only popularized this approach and quite a job they did.

Today, the idea of solving problems by design has become one of the most popular ones on the planet. Quoting IDEO, “[Design thinking] brings together what is desirable from a human point of view with what is technologically feasible and economically viable.”

That’s why Design Thinking is a great tool for Product Discovery processes. It focuses on the following pillars:

Empathy

It’s all about understanding the needs of potential users of a product, problems they’re facing and their importance. It’s about putting yourself in their shoes and trying to dive into the feelings of your customer base.

This stage is inevitably connected with interviewing people. You want them to use a demo and share their feedback. Or if a product has already launched then you want to find real user stories.

At the end of this stage, the participants need to define the problems that they’ll be trying to address next. This is frequently considered a separate step of the Design Thinking process but since it’s inevitably connected with ‘Empathy’, we’ll keep them together.

Ideation

This stage is about coming up with many, even the wildest ideas. The only condition – they should be an answer to the established problem.

It can be a feature you’ve been thinking of for a while. It might be a marketing approach that could turn out to be revolutionary. Or, it can be only a simple project that came to your mind just now.

Participants are also encouraged to build upon the ideas of others. This has proven to be a powerful way of getting even better ideas. This stage is not for judging ideas or even discussing them. It’s to release creativity, fill the board with thoughts and move on. Go for quantity, not quality.

Experimentation (also referred to as Prototyping)

In this stage, we go through the ideas outlined in the previous stage and analyze them one by one. Can it solve the problem? Is it feasible? Are we able to build it?

We might throw some good old MoSCoW into the mix. The end goal of this stage is for the team to come up with ideas for prototypes to address the given problem. Such concepts are then broken down into pieces and put in motion.

Testing

Prototypes are built, and the design team is now tasked with measuring how a prototype is performing. Are the people using it as expected? What are their thoughts? Do they come back? Are they complaining about the lack of something? The goal of the team is to gather as much data as possible.

The process doesn’t end here because the prototype you’ve just delivered won’t be the final version of a product. It likely won’t even be close.

Depending on the results of testing, the team might go back to:

Empathy – if they define a new or different problem during the testing
Ideas – if the ideas generated were not enough to address the problem
Prototyping – if the hypothesis was right, but we need a different prototype

And it can go on and on like this. The flow of Design Thinking is very flexible in nature. Some facilitators, to boost creativity, might split the team into groups and have them work on the same stages simultaneously.

Or, designers can collect information throughout the whole process. They could be building prototypes while the team is still discussing ideas.

In other sessions, several different groups could be going through the whole flow. As a result, several prototypes might be put in motion. There are many, many approaches to doing design thinking, but over and over again, the method proves to get the job done. Speaking of…

Jobs to be Done

Jobs to be Done is a powerful framework that has gained significant popularity among innovators. It takes a bit of a different approach towards problem-solving. It encourages participants to look at a problem, not from the perspective of a user (typical personas approach), but instead they focus on a ‘job’ a target is trying to achieve.

A job can be defined as a particular change a person wants to achieve in their life. Such an approach pushes you not to look into building an improved version of an existing solution. Instead, you should find a completely different way of solving a problem.

To give you an example – let’s say someone struggles with cutting a meadow around their house every month. They have a regular grass mower, but the field is large and it takes a lot of time.

Many entrepreneurs would think – let’s build a better, faster and more precise grass mower and sell it at a premium rate. It could work if you keep the price reasonable.

Jobs to be Done takes a different attitude. It tries to dig into the core of a problem, looking for an actual improvement a person is seeking. Do they want their grass cut? Yes, of course, but deep inside, they don’t care about the process of cutting the grass efficiently.

Instead, they want to have a good-looking garden, so they can feel good about themselves and their neighbors can admire them (or hate them a bit less, you pick). Also, the less effort they have to put into it, the better for them.

The JTBD-influenced group would look into making a genetically modified grass. It would only grow to a certain length, solving a problem. Would this satisfy the job a person is trying to get done? Most definitely.

OKRs

OKRs can be also used during the Product Discovery session.

In case you’re not aware of what they are: OKR stands for Objectives and Key Results. It’s a way of making ambitious plans and setting specific goals. These will allow you to measure if you meet your objectives.

As an example, an Objective “launch a product on the Spanish market” can come with a Key Result “reach 10,000 signups and 2,000 weekly active users”.

OKRs are meant for ambitious goals, so often reaching a KR of even 70-80% is considered a success. If you reach 100% of the key result without any serious struggle, the goal was likely not ambitious enough.

When doing a Product Discovery, teams should come up with user personas. They will help them visualize their goals, struggles and anything that might influence the way they use a product. Then, participants need to think about the goals they want a product to reach – these will be the objectives.

Usually, people are stimulated to come up with as many ideas as possible. Each is then discussed with the group. Ideally, 3-4 ideas should become Objectives.

Following that, the team comes up with Key Results for a given Objective. Each idea is, of course, discussed and then, when a consensus is reached, the teams write down their new OKRs.

As was the case with the other approaches, it’s hard to expect that the initial OKRs will stick for a long time. That’s why the team needs to be ready to revise their goals as they go. They should keep them as close to a current reality as possible. Of course, they still need to be ambitious. Settling for a trivial-to-achieve result shouldn’t be an option.

Due to the nature of OKRs, they should be also combined with other Product Discovery Methods. After all, they only focus on the objectives of a product, they don’t provide much support at the brainstorming stage. Regardless, OKRs make for pretty good metrics for product discovery.

RAT

Another interesting approach to product discovery is the method called RAT – Riskiest Assumptions Test. It puts a heavy focus on doing multiple tests of even the smallest prototypes. This way, the team can gather valuable data from clients as early in the process as possible.

RAT stands in opposition to what many entrepreneurs call MVP (Minimum Viable Product). By definition, MVP was meant to be a very basic version of a product, aimed at validating some hypotheses. Unfortunately, these days many, many startups spend months building their MVPs. They hardly gather any customer feedback and end up shipping products that might as well turn out to be useless.

Riskiest Assumptions Test is about determining the biggest assumptions about a product – its features, market, business model, etc. Participants try to come up with the simplest possible ways of validating these assumptions. The shorter the time needed to validate them, the more tests they can perform within an available runway and the higher chance of finding the right product/market fit.

BRIDGeS

BRIDGeS is a product discovery and decision-making framework created by Railsware. It’s a method we’ve been using at Railsware for many years. It gave birth to various successful products, and we’re confident that, when done right, BRIDGeS has the potential to be one of the best product discovery frameworks.

A BRIDGeS product discovery session is usually a one or two-day intense meeting. The session starts with the topic introduction. Participants introduce all the existing materials, like research, surveys, analytics data, wireframes, etc. The team defines the main Subject(s) that suffer from a problem and want it to be solved. Then, the team analyzes Benefits, Risks, Issues, Domain knowledge (any supporting data), and Goals of the Subject(s) and prioritizes them to focus on the most critical things.

Once the team has a deep understanding of the problem context, it moves on to finding solutions. It’s easy to offer 3-4 Solution variations when you see what aspects are the most important. The team can use the same set of descriptors to inspect Solution variations and make an informed decision based on all risks and opportunities each variation entails.

Once the Solution variation is chosen, the team creates a feature list making sure every critical aspect is taken into account. Eventually, the team prioritizes features and puts them on a roadmap.

Such a process gets everyone on the same page and enables you to deeply understand your product context. It’s especially recommended for the initial stages of development as a good intro to product development.

Summary

Whichever method you choose, the key deliverables of the discovery stage should be:

A clear understanding of customers, their needs and the problems they’re facing
A clear idea of how your product will overcome those challenges The more data you have and the better. If you can understand it and use it to your benefit, the higher the chance of success for your product.

This wraps up this guide to product discovery. I hope that by now you know WHY it’s important to run a product discovery, WHEN it should happen and HOW product managers ought to implement it.

If you believe that you and your team have a great idea, you might be right, but don’t forget to double-check with your clients.

Steve Blank wrote in one of his books “There are no facts inside your building so get outside”. He might have been onto something.

Thanks for reading guys. Share your feedback and, if you want, check out Railsware's blog where this post was originally published :)