The advantages of ‘builder-based’ product design (and how to do it)

Introduction

‍

As I look around the current ecosystem, I’ve noticed that many successful products share similar approaches and values. Specifically, these products share a product design approach that I see as essential: the “Builder” approach. Simply put, creating a product that the customer can easily adjust to meet any use case within a set of business processes. 

The builder-based approach is way more than a trend if you're asking me. Here's why I believe developing a 'builder' mindset can deepen the success of your product teams.

‍

The problems with ‘non-builder’ products

Many products are planned and developed with a specific process in mind. Usually, they are built to perform specific use cases but can fail when there are anomalies or changes to the process. 

‍

An HR Management System Example

Let's consider an imaginary HR management system for small to medium-sized companies. Its core capabilities are:

• Onboarding new employees - A set of tasks that employees complete as part of the onboarding process. Teams can change the task list according to the relevant team.
• Vacations - Employees can ask for a vacation through a self-service portal. This goes to the relevant manager, who can approve or decline the request.
• Employee evaluations - perform and document the performance review between employee and manager and record new goals and objectives.

The product was used within some small high-tech companies and saw general success. It met all the organizations’ HR needs, and both the HR managers and employees were happy.

‍

But then, several issues arose - 

• The onboarding of a new employee forced the organization to perform some predefined tasks in a particular order. However, these tasks were not relevant for some organizations. For example, ‘Introduction to other teams’ is irrelevant for small companies with only one team.
• The self-service portal was not suited to organizations that didn’t have an approval policy because it required the approval of someone in the organization by default. 
• Over time, the small startups began to grow, and their needs changed. As a result, the product’s capabilities no longer suited the company’s requirements. For example - the employee evaluation workflow became more complex and couldn't be implemented inside the product for each organization without heavy code customizations. 

‍

This ‘tailor-made’ approach to the system’s design meant that the product team had to perform multiple patches to solve issues as they appeared. In addition, as customers' needs changed and new customers with specific requirements came on board, the team could not scale their solutions to meet demand.

Our imaginary product team faced many issues caused by their product design approach - 

• Change management issues - organizations are forced to adjust their processes to the product. This means that learning the system is harder for the employees and makes them more likely to revert to their old systems and avoid using the product.
• One size does not fit all - this product could answer the main use cases - for example, employee onboarding tasks - but neglected many sub-cases such as specific tasks for small teams.
• The product cannot grow with the organization - companies changed their processes, and the product could not adapt and keep up, for example, when the employee evaluation workflow becomes more complex.

‍

{{cta_1}}

‍

The “Builder” Approach

The issues mentioned above could be solved by adopting a “builder” mindset at the product’s design stage. 

Many products are now emerging with the “builder” approach and values across various industries: 

• Productivity - Monday, Notion, ClickUp 
• Collaboration Platforms - Miro
• Internal Platforms - Retool, Budibase 
• API Management - Postman 
• Developer Portal - Port 

‍

{{cta}}

‍

What makes these products so good? 

Easily fit the organization - instead of an inflexible list of capabilities, these products give the organization a baseline to establish its processes and workflows. This makes it easy to incorporate the product into the organization’s processes with minimal resistance from employees and key stakeholders, and provide a great developer experience (DevEx).

Answer multiple use cases - large organizations can have different versions or complexity levels of the same process in numerous departments. Therefore, these products can be adjusted for multiple use cases and be used seamlessly across the whole company. This makes them a more attractive proposition for large organizations.

Can be adapted to fit changing requirements - companies are constantly evolving, and their processes are continually changing. Therefore, these products have the flexibility to be modified according to the organization's changing needs and stay relevant over a long time. 

‍

How To Develop A Builder Mindset 

As a product team member at Port, I have learned to construct a seamless “Builder” experience, particularly in the developer portal space. 

Here are three fundamental principles that I would recommend you consider: 

‍

1. Let the user build what they want, how they want

1. Companies should tailor the product to the customer’s business processes but generic enough to provide value for a range of use cases.

2. It’s essential to precisely define the builder’s requirements so that you can create a “building experience” that suits their background, environment, and technical expertise. For example, API-first products are great for developers but not for sales engineers.

3. Your system’s data model should be as streamlined as possible while providing your customer with the tools to create their model inside the product.

4. In Notion, the most basic entities are databases and items. Users can leverage these building blocks to create complex processes with their entity types. For example, a project manager can create a “tasks” database and a “milestones” database and then link them to create a yearly work plan. These entities (tasks and milestones) do not exist in Notion’s architecture but can be created and managed with Notion’s building blocks in the user’s workspace.

‍

2. Know your ecosystem and provide templates for easy onboarding

1. One of the biggest challenges for builder-oriented products is that it can be hard for your customers to get inspired and imagine what they will achieve. With so many options and things to build, it can feel overwhelming when your customers start.

2. Your mission is to learn your customer’s different business processes and provide templates based on them. These templates need to include the details required to set up a specific process, so your customer will be able to start experimenting with your product quickly.

3. In Miro, their beautiful templates page is a great example of such a system. Users can draw and organize their thoughts on an endless canvas, and the templates page helps them get started quickly. It contains a variety of pre-made setups, ordered by their use case, so the user can easily find the relevant template and copy it to their canvas in one click.

‍

3. Build a community of contributors to enhance the product 

1. This one is related to the previous principle. When applying a "builder" approach to the product, users can use building blocks to create a community - a place for users to discuss and share their implementations and best practices. This community aspect adds much more depth to the product's offering.

2. Like templates, community content needs to be an integral part of the product. The user will import community templates, use them in their workspace, and contribute by publishing their content and editing others. 

3. For example - Postman (an API management platform) has a large community with many developers and companies sharing their APIs through the Postman platform. Users can learn how top companies manage their APIs, use them in their projects, and contribute by forking the API and creating “pull requests” to merge with the original API collection. This intelligent move by Postman created a large community of API developers and consumers who add valuable content every day for the entire user base.

‍

‍

I hope you find some of this content helpful, and I encourage you to implement some of these concepts in your product. 

Drop me a message to discuss anything here at dudi@getport.io or my LinkedIn profile

{{ebook}}