Launching a Developer Centric Product
From Strategy to Production
Consolidating and Simplifying the Portfolio
When hired at EasyPost in 2023, the company had recently finished an acquisition spree creating a portfolio of over 10 products. Each product had its unique angle in market, but a lot of their base functionality was the same. Since all of the products were built by different companies and teams, there was no unified tech stack and features had to be built on a per product basis.
Working with the VP of Product we developed a strategy on how to consolidate the offerings from the user perspective and what offerings EasyPost wanted to push to market.
We first started by identifying trends in customers and what made us unique in market.
Competitive Analysis
EasyPost started as the only API carrier connection back in 2012. Since then, many competitors have been created and had begun to surpass EasyPost in market.
EasyPost's leading product and focus is its API, so it acquired UI based offerings for customers that wanted a simpler SaaS experience. As we started to look at various ways to consolidate experiences and what we could offer, we identified and focused on 2 main competitors.
ShipStation targets the "messy middle." The UI is built around handling lots of customizations and handling advanced order management. They were perceived as the go to shipping software for high growth companies. ShipStation acquired ShipEngine, a shipping API, to handle their customers that wanted more flexibility and to build their own tooling.
Targeting startups and smaller customers, Shippo has gained a lot of marketshare through advertising and the right store integrations. The UI is simple, easy to get started with, and focuses on less complex needs. They released an API to accommodate larger customers, but their UI is limited in handling complex needs.
Product Proposal and the Approval to Create the Forge Product
We proposed a lineup of four products, each aligning with a target customer profile. One of the four products, which eventually became the Forge product line, had the most leadership alignment and most clear upside to begin development on.
Target Customer Profile: Whitelabeled SaaS Shipping
When looking at the existing customer base of EasyPost, some of the most profitable and happy customers were SaaS companies that utilized our API to build digital experiences of their own. Loop Returns, Walmart Marketplace, and PirateShip use EasyPost's API to service their label purchasing. For every feature we released, they wanted API documentation and had no issue with the dated and limited UI EasyPost offered.
We discussed with Sales and Support for similar examples of customers wanting to use our API to build their own experiences but decided against EasyPost as their chosen solution. In those deals, they wanted the strength of our API. However they needed UI for less technical teammates to make adjustments without developer teams and wanted to offer UI experiences downstream without having to build their own from scratch.
Concept Mocks and User Research
Two Users, One Experience
We identified two main users the new product would need to accommodate: Developers and Logistics Managers.
The concept mocks focused on highlighting how the product would adapt and show different information depending on who the user logged in was.
Internal User Testing
EasyPost has a product that targets developers. That made user research easier as developers could be found outside and inside the company for prototype testing. There was a large variety of experience levels and tooling expertise at the company from all the acquisitions. We were able to show mocks and Figma prototypes to our engineers to test the proposed UIs and user flows.
Feedback was very positive on the UI, with most of the critical feedback indicating a lack of documentation within the product. We took this feedback and added blue highlighted documentation throughout the more Developer centric pages.
Existing User Testing
We worked with CSMs to get on calls with existing users that met the whitelabel customer profile. These calls focused on product functionality and where the customer felt their current experience fell short with EasyPost.
While getting on calls with long time customers we were surprised by the amount of times a better dashboard was requested.
The top findings were:
- Logistics teams struggled to work with their Dev teams to get changes made to carrier rate cards, rate selection, and adjusting experiences based on their customer groups.
- The raw data coming through Webhooks was acceptable for some, but many wished there was more reporting in the product.
- Getting financial reports from EasyPost was not intuitive for finance teams. They also did not want to give their developers the permissions to see financial data or accounts.
Prioritization for MVP and Final Mocks
The research came back with a very large list of new features but we narrowed it down to two main focuses. First, establishing the new UI foundation with all the existing EasyPost functionality and second, building in new data visualization tools. Specifically enabling sub account specific reporting.
The product took 5 months to launch.
Success Metrics and Lessons Learned
Win: Research was Validated
Many of the new feature requests that came up in user research did not make it into the MVP. The only category that did was Sub Account Dashboards and Reporting. These were a huge hit out the gate, but we immediately started getting asks from customers that were not involved in the research, for the features next on the roadmap.
We spent the next quarter building out the top two requests: FlexRate and SubAccount Grouping.
Win: UI Investment Paid Off
Development Speed: Since we had spent the time building the product on an entirely new front end, the front-end team was able to add the features within a single sprint of the back-end being ready.
This was a huge win for the team as previous UI based work for new features took at least 3 sprints on average to complete.
User Feature Adoption
When Customer Success began demoing the new product to existing customers, we heard the usual, "wow this looks visually better."
We also heard something unexpected. Many of our existing customers, despite being helped and informed by their CSMs, did not know half of what our API offered.
After launch we saw increases in:
- Insurance Usage and Adoption
- Increased by 21% within two quarters
- Sub Account Creation
- Increased by 32% within one year
- Adoption in Recommended Wallet Carriers
- Increased by 10% within one year
Lesson Learned: Not Every Existing Feature Needed to be part of MVP
Based on the research we had, all of the existing EasyPost experience had to be brought over for initial launch of the product. In reality, once launched, we noticed customers did not care about or use sections of the new product. If we had been able to better identify which features customers needed, we would have been able to launch within 1 quarter instead of 1.5 quarters.
Where the mistake was made:
- We made the decision based on API usage that wasn't fully scoped to the target customer profiles.
- The usage data of EasyPost's flagship product did not have an easy way to segment usage data. While we did our best, when reflecting, we noticed this decision based on the data available led us astray.
- Assumed that existing customers would not move if it wasn't a 1:1.
- Many users used the new product as an excuse to use newer API call offerings and optimize their implementations.
