Postman on Designing for the End User and Product-led Success

If you start digging into the origin stories of leading software companies, you’ll notice a pattern. A lot of companies emerge out of founders’ personal pain. Technical founders are an enterprising breed who detest inefficiency. If they are suffering from some lack of shortcomings in the available tools, it only makes sense to them to go out and build something better. And sometimes that something better turns into a viable business idea.

That’s pretty much the story behind Postman. We are the only complete API development environment on the market, and the reason we’re here is that I got tired of struggling with API-related issues in my own projects.

I was working at Yahoo Bangalore when I first had to confront the inadequacy of existing API tools. Most of what we were building used APIs as the glue between the backend code base and the frontend code base, but there was a lot of friction in the process.

I went on to found a small company called TeliportMe that built applications for Android, iPhone and the web. We had a single API that powered all these applications from the backend, but developers would typically write their own clients. Having each developer bring their own tooling left us with a very convoluted experience that had a steep learning curve and carried big risk for failure.

It was around this time that I decided to try to build something that would be more convenient (as well as reliable, elegant and flexible) for my own purposes, and that’s how Postman was born. Since launching in 2014, we have grown to a team of 150 employees who operate all over the world. Our product is used by nearly eight million developers in more than 400,000 companies worldwide.

We built this company and achieved this success by staying true to the thing that got us started: alleviating the end user’s pain. Based on our own experiences as developers, we adopted a product-led approach that keeps us focused on our users and our community rather than on a traditional sales model. And we supplement our customer-centric strategy with data-driven insights that help us validate our gut feelings.

Two Design Principles for Product-led Companies

Product led growth models lead to fundamentally better products because they are designed for the end user first. Instead of being designed for the buyer—who may or may not be a user—they are designed for the person who will experience the product first hand. To do right by this person, you need to really care about who is using the product, why they need it, how they are using it and whether or not it is solving their problem.

We were naturally product-led right from the start, and had immediate and unfiltered insight into our user base because we were our own first customers. Looking at the product through that lens, we arrived organically at a development strategy based on two design principles that we still use today.

Keep it Simple

Our first principle is to keep our product really, really simple. If someone comes into Postman to send a request, we want them to be able to complete that job really quickly. We avoid overloading the experience with too many extraneous things. Instead, we focus on getting to that first unit of value as soon as possible. Once people are hooked in and getting their work done, we continue keeping things simple so that there isn’t any friction between those first steps and next steps, whether that is doing more things with API development or integrating with other workflows.

Embrace Your Community

The second principle that has served us well since day one is taking a community-driven approach to development. We’ve built a user-driven feedback loop that allows us to observe what users are doing in the product and then bake those behaviors and features back into additional flows. Over time, our observations uncovered two key insights that helped shape the Postman product.

The first insight was that developers really didn’t have the right tools for working with APIs. They were often forced to repurpose existing tools, many of which were sold by other vendors to specific functional areas or companies. That was a far cry from the single tool we wanted to build. The second insight was recognizing that since these tools were designed for specific use cases and then hacked together, they didn’t naturally lend themselves to collaboration.

Keeping simplicity in mind, making sure we really listen to users, and then baking their insights back into the product cycle have helped us to continuously innovate and improve on the Postman experience overall.

Customer Success Instead of Sales

The product-led approach and these core design principles have always made a lot of sense to me. As I learned more about product-led strategies, I became increasingly interested in how this approach affects the marketing and sales functions as well as the customer experience.

At Postman, we have a customer success team instead of a sales team. We initially implemented this strategy based on what we saw other successful companies, like Atlassian, doing. We stuck with it because seeing how it enabled us to build a really good business made us firm believers. By focusing on helping our customers succeed instead of selling to them, we are able to join our users in their journey. They get excited. We get excited. We create a sense of everyone being in this thing together. This helps us build stronger customer relationships, which then helps us stay ahead of the market because they provide direct insight into key user challenges.

At this stage in our company’s evolution, we’re working on figuring out new ways to communicate with users at scale. It’s a common challenge for a growing organization. Right now, we’re focusing on how to scale our support function. Each time we get a working solution done, that’s one more way we are able to differentiate ourselves from our competitors.

The Data-driven Advantage

One of the other key opportunities for product-led companies is the ability to take advantage not only of real experimentation, but also truly data-driven decision making about product features and go-to-market strategies. We are a very bottoms-up business, which means we need to be conscious about every interaction with our users—inside and outside the product—to ensure that we’re delivering value in every way possible. Data plays a big role in helping us measure and quantify this.

There are a few things to keep in mind if you want to take advantage of your data:

Own your data (or at least know where it is and have ready access to it)

You don’t want to have to jump through any hoops or go through a vendor to get at your own data. At Postman, we hired engineers and data scientists early on and built a data infrastructure pipeline.

Understand that data isn’t magical

Often, people who aren’t data experts have unrealistic expectations about what it takes to extract insights from data. You don’t just wave a magic wand. You have to work closely with data scientists, explain your product, work out exactly which key metrics you need to look at and so forth. There’s no one-size-fits-all solution. You need to craft the data strategy that makes sense for your specific business. And it’s key to work with someone who can filter out what you don’t need. You could easily drown in data if you’re not careful.

Have a process for working with your data

In a similar vein, you will get more out of your data analysis if you have a set process. A basic but effective approach is to:

• Develop a hypothesis and then frame it up as a question.
• Propagate the question with individual teams and across other functions and the higher levels of management.
• Once you’ve collected input from the various teams, work with your data science and engineering teams to look for ways to answer the question using available data sets.
• Then, as you start to uncover insights, reevaluate your hypothesis. Often, whether your analysis validates or disproves your hypothesis, the process will lead to more questions than definitive answers. This is your opportunity to keep digging and see what other information you can uncover.

As an example, one hypothesis we explored led to fundamental changes in our business model. We built our company on the belief that APIs form three kinds of relationships: technical, business and people. When we started exploring the data around this idea, we discovered some interesting things. We saw that public APIs were sharing their Postman collections, which were then being consumed by third-party developers. (Collections are a series of API requests). We then did qualitative studies between teams within companies and found that they were also sharing collections, and that their workflows were tied together.

In both these cases, we could use our data to visualize the networks that were forming. More importantly, we could recognize that users wanted better sharing and collaboration capabilities. This insight led us to open up our free trial to allow people to invite as many people as they wanted and collaborate up to a certain limit. This led, in turn, to a massive increase in conversions.

Avoid bad science

Too many so-called data-driven companies fall into the trap of skewing their results by viewing data with the intent—conscious or subconscious—to prove their case. It’s human nature, but not the most effective way to work with data. This is why, very early on, we set up a process of trying to discover if our hypotheses were wrong. Rather than trying to make the data fit a predefined conclusion, we are very intentional about testing out the negative hypothesis to make sure that we’re getting the most accurate information possible.

Stick with Your Instincts…and Your Users

After all these years, we’re still on a journey. We’re still learning, every day. But we feel confident that the core culture we’ve built around our product-led approach is the right choice for us. We stay focused on our end users and on solving their problems. We keep things simple, and we listen to our community. We make them our partners in ensuring that Postman exceeds their expectations.

Listening to our users is a major part of our product-led strategy. We have learned to believe them over any expert. There was a moment when we felt we had to bring in some functional expertise. We wanted to get the “best” designer, marketer, etc. to help us move forward. But, what we learned was that each of these experts brings their own mental models from their respective disciplines; and those models don’t always gel well with what really resonates in your community and with your team.

Over time, we realized that the initial thoughts we had about how to build the best product for our users might not be applicable to other products, but they were the exact right principles for building Postman. It made sense, for instance, for our three founders to put time in on the support team. And it didn’t make sense for us to drop support for our freemium users (even though we saw a lot of other companies choosing that path). We learned to respect our instincts and our users.

Your best bet is to make decisions based on the value your users are getting. Make that your compass rather than relying on a predefined success template. Put your end users first and let your product take the lead in developing the relationship, and you can do amazing things.