Product design for rapid growth
At Postman, we make developer centric products that help people build APIs faster. Product design occupies a key role in our growth to more than 3 million users today. I recently spoke about our approach at the NextBigWhat conference. These are a few strategies that really worked for us:
1. Zero “traditional” marketing
We’re a small team of 3 designers and 15 engineers. So we focussed all our time, energy and money on making the product better. We didn’t spend money on online ad campaigns, hiring a sales team or even any typical tech events (not yet). Instead, we concentrated on improving workflows and understanding the people who use Postman. We focussed on getting the product to a place where it could market itself.
At the same time, we maintained our blog, website and email channels so that any inbound interest was handled well.
2. Have the right kind of design discussions
When you aim to achieve a lot really quickly with a lean team, it is important to observe what your product design process sounds like. What are you talking to your designers and product team about most of the time? Are you focussed on colors, fonts, layout, templates, icons, buttons and assets? Or are you having more meaty discussions around user flows, funnels, solving customer complaints and testing. Make sure that your product design discussions are around effective things like reducing drop-offs and increasing engagement.
3. Make all the UI components
There is a huge gap between designers and developers today. What really helped us bridge this is making all the modular component sets for the app. We use awesome tools like Zeplin to collaborate on these massive component sets. This greatly reduced the amount of back and forth on things like button sizes, layout, hover states, icon assets and hex values. Now when engineers and designers talk, it’s about making the flows better and new ideas for the product.
Some designers feel that making these massive component sets may limit their creativity, but I don’t agree. As long as you get your basic design system right and your basic set right you can get as creative as you want. For example, Tangram is a great example of a puzzle with infinite patterns made of just seven pieces.
4. Design decisions should always be in context of the result you want
At Postman we work towards really specific goals like getting people to go from manually testing APIs to automating so it’s less painful and time consuming for them.
This is all about getting to a point in your process where you are practising goal oriented design instead of opinion oriented design. For example, do you want more app downloads or more sign ups?
5. Ship, ship, ship
Ship as much as you can, as fast as you can, as frequently as possible. (Obviously ship the right way and ship MVPs)
This is part of being action-oriented and reducing the hypothetical. The faster you get to market, the quicker your design will be truly tested. Don’t be afraid to make mistakes. Focus on shipping, testing, prototyping, sketching and making things. Instead of iterating internally in your team for 3 months. It could be really fun to brainstorm and explore concepts with your team for really long. But that just means you are taking even longer to ship to the real world. Minimize random opinions, meetings and too much verbal concepting.
Every team evolves their own method to get to an ideal productive state. Whatever method works for your team is best. What really works for us is weekly demo days. Every Wednesday every person on the team showcases what they did during the week instead of talking about it. For example if a backend dev did a 3% performance improvement, s/he shows it with a graph. We found this weekly cycle to be super rewarding and motivating for everyone.
6. Build up network effects
Focus on parts of your product that encourage usage. This depends on your product and the kind of service model you have. A network effect doesn’t simply mean getting more people to use your product. It’s about becoming the wiring in the network with your product.
One example of this is our Run Button. It lets developers use and run an API in seconds. All you need to do is embed it anywhere on the web and when you click on it, it launches Postman and lets you explore and test the API.
We first thought of testing this new product idea with a few Postman users who really like us. What ended up happening was that it spread like wildfire and now teams like VMware have it on their Github page. A really wide range of awesome API publishers use it now including the likes of Postmates, Sails, Best Buy and even Transport for London.
So that’s one example of how focusing on the part of your product that encourages this type of behavior easily (like a button that can be embedded anywhere) can help you grow quickly.
7. Validate your product in the wild
Controlled conditions are not the best predictors of success. Product validation to us means that people are using the product IRL, per person usage is increasing, people want their friends to use it and they want to buy it. What it isn’t is if focus groups and surveys say your product is a good idea. A POC app that doesn’t really work isn’t a good way to test validation. A lot of media buzz is great but not the best predictor of good product validation.
8. Talk to people who use your products everyday
We have conversations with our users through various channels like Twitter, Zendesk, Github and Hangouts. It is clearly important to understand your users when you are building a product. But it is also crucial to have unstructured conversations. Twitter conversations and topics for example follow a specific format and audience type. A Github interaction is similarly limited to the given format.
We found that chatting is the best way to break out of formatted conversations. We started a Slack community where we chat with people who use Postman about general topics like tech and APIs instead of just the product.
The problem with common user research processes is that it’s all planned out in a rigid timeline. The team does a bit of research before starting on a new project. Then there is a stage of research mid-way followed by a final bout of validation. This is great of course. But what helped us is going beyond that with chat and maintaining a frequent almost daily interaction. This is crucial to gain a level of empathy with people and avoid thinking of them as “users” “customers” or “personas.”
And get everyone on the team involved. At Postman, each person on the team — engineer or designer replies to support tickets.
“Users don’t know what they want”
Are you sure about that?
This is a really popular saying in some circles, but please question it. Given the right tools and methods, people are great at communicating what they want. If you are looking at surveys then of course the data isn’t accurate. But in the wild if someone doesn’t like your app they will immediately delete it from their phone or laptop. People will always use and buy what they feel like. And that is truly “what they want.”
Let’s not underestimate people, especially today.
