Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. It’s one thing to iterate on an existing product. It’s a whole other challenge to identify brand-new products to offer.
The same is true for API products.
The difficulties you face from going to 0 to 1—understanding your customer, identifying what will differentiate your product, building early versions of that product, and actually finding customers to use it? They still exist, even when your product is an API.
And just because APIs are slightly more technical products, that doesn’t mean that you can’t apply discovery to them. In fact, we’ve started publishing a series to make the case for why discovery is critical for APIs. In case you missed it, here’s what we’ve covered so far:
- We introduced APIs and how they work.
- We discussed the most common challenges developers face when starting with a new API.
- Teresa shared her own experience with using APIs and why it convinced her this is an area where much more discovery is needed.
- We published a Product in Practice story about how discovery helped uncover usability issues with an API.
And today we’re excited to share this 0 to 1 Product in Practice story about a product that didn’t have an existing API but saw the potential business case for building one.
We’ll hear from Chi Phan, the senior product manager who was brought in to oversee this process.
It’s worth noting that many API teams don’t have product managers. It’s more common for developers to decide what to build. This story stands out because as a PM, Chi used discovery tactics like customer interviewing and story mapping to shape the development of an API.
We’re continuing to source stories like this one, so if you’ve used the discovery habits for an API product and would like to share it with Product Talk readers, please get in touch to let us know!
Meet the Continuous Discovery Champion, Chi Phan
Our continuous discovery champion for this story is Chi Phan, a senior product manager. Chi works on a product where consumers buy a service from a vendor and Chi’s company fulfills the service. Because of this setup, Chi’s company has to keep the vendor up to date on the status of the service so the vendor can update the consumer.
Here’s a quick overview of the major players we’ll be referring to in this story:
- Consumer: A company or a person who requests the service
- Vendor: The company that sells the service to the consumer, but doesn’t fulfill it
- Chi’s company: The company that fulfills the service the consumer requested
When Chi joined the company, the fulfillment of the service and the communication between her company and the vendor was manual.
This manual order process required a lot of back and forth between the vendor and Chi’s company. As a result, vendors didn’t have the operational capacity to create and manage all of the orders that they received from customers. Chi’s company was also limited in how many orders they could manually process.
The hope was that an API could relieve both of these bottlenecks. If so, they’d be able to process more orders and make more money.
Chi was hired to evaluate if an API could automate some of this process.
To better evaluate if an API could help, Chi needed to understand both what her internal colleagues were doing to manually process an order and what the vendors were doing to create and submit an order.
Chi’s Challenge: Taking an API from 0 to 1
Because there are several players and steps involved here, Chi first spoke with internal people at her company so she had a clear idea of who and what was involved.
Starting with Internal Discovery: Understanding the Manual Process at Chi’s Company
Based on her conversations with her coworkers, Chi created a step-by-step outline. When a consumer purchases the service from the vendor, here’s the manual process that was happening to fulfill the order:
- The consumer asks the vendor to perform the service
- The vendor creates an order that contains the details of the consumer
- The vendor submits the order
- At this point, Chi’s company’s compliance ops team finds out where a consumer is based. Depending on the country where the consumer is located, Chi’s company may need to request different documents from them in order to fulfill “know your customer/know your business” (KYC/KYB) requirements, an identity verification process that’s used to prevent financial crime. This was a big part of the first bottleneck that needed to be alleviated.
- Once Chi’s company has all of the required documents, they verify the information that the vendor provided and fulfill the service
- The vendor follows up with the consumer about the status of the service and when it will happen
After realizing how many manual steps were involved, Chi wanted to see if there was a way for her company to programmatically fulfill those orders and check the status via API instead of doing it manually.
Chi knew that competitors were already automating much of this process, so streamlining it at her company had the opportunity to impact customer retention. This convinced Chi that there was a business need and she should continue her discovery efforts.
As an early step in thinking about how to automate this manual process, Chi decided to story map the process her team followed. First, she started interviewing different teams within her company to understand the workflow, shadowed the teams to see what their day-to-day looked like, gathered examples of vendor orders, and went through the process for the top five countries her company served. She also learned about the KYC process for the top countries they served.
Through this process, Chi discovered that while the KYC process required a lot of manual back and forth for some orders, only 10 of the 60 countries they served required extra documentation. This meant that not all orders were affected by this complexity.
A visual workflow outlining the step-by-step process for verifying customer identity and coordinating with the previous provider before fulfilling an order. Click the image to see a larger version.
Moving on to Discovery with Customers: Understanding Vendors’ Challenges
Chi also spoke with the vendors who were selling this service to consumers to better understand what they needed to do to create and submit an order.
Chi started sitting in on quarterly business reviews with top vendors. These were review sessions Chi’s company’s account management team was already having, and they gave her the chance to ask vendors about their order volume. By learning more about a vendor’s process for submitting orders, Chi realized that the order creation process took so long that they sometimes had to push orders to the following month.
When a vendor manually submitted an order, about a third of the time, Chi’s company had to follow up with them to collect the appropriate KYC documents. When this happened, it took a lot of time and a lot of back and forth. If they could streamline the process, they’d be able to process more orders (and thus increase revenue).
To make this happen, Chi needed to connect with her vendors’ product and technology folks. In these conversations, she asked about their specific workflow to handle an order from consumers, the steps that the order went through, how they followed up with the status of the order, and what were the most painful and time-consuming tasks.
The vendors told her their biggest problem areas were order creation and follow-up on an order’s status. These discussions led Chi to see that many of the vendors in her company’s top countries experienced similar problems.
With this knowledge, Chi was ready to start visualizing the process. She explains, “I wireframed with vendors to lay out the inputs and the outputs they need for each step, potential conditions and errors. I stayed as generic as possible in that process so that we could serve as many vendors as possible and we were not tied to a particular vendor.”
This diagram illustrates the required and optional input fields for an API endpoint to create a draft order, along with the conditions that must be met and the expected output fields returned by the system. Click the image to see a larger version.
This process also uncovered variation in the way different vendors work. Chi says, “Each vendor has a specific way of operating. Some will require you to put their own order reference, and those orders could be a combination of consumer name, date, and their internal reference. Or they could be their own internal reference. So rather than doing bespoke external reference, I created an input for external reference which is included into our draft order, and anytime we return an order later on.”
Here is how Chi story mapped how an API might better support the vendor process:
- Vendor looks up required documents. (This step allowed the vendor to look up the required KYC documents that they needed to submit with the order, eliminating the manual back and forth with the compliance ops team that was happening before.)
- Vendor creates a draft order.
- Vendor submits the draft order.
- Vendor integrates with a webhook system to receive status updates.
- Vendors could cancel if they wanted, with a cancellation fee.
- Vendors could delete a draft order.
Next Steps: Sharing What She Learned with Stakeholders and Co-Creating with Customers
Based on the conversations she had with internal colleagues and vendors, Chi began to collect her insights and share them with her company’s VPs to confirm that they should build the API. Here were a few of the main reasons she argued this was the case:
- Chi’s company could process more orders, resulting in more revenue
- Vendors could reduce the time it took to create and submit orders, resulting in more orders (and thus more revenue)
They didn’t need to create tailored processes for all 60 countries where their vendors were located since only 10 of those countries represented the most complicated cases.
Chi brought the proposed story map to the development team and they created a high-level estimate. Chi worked with the development and devX team to co-create the REST API specifications. They published the REST API even before coding, and she shared this with the vendors she had interviewed to see if they had any concerns.
Chi’s company did a couple of iterations with their specifications. They eventually came up with a design that was clean and that they could launch in a subset of countries (due to regulation requirements).
Throughout this process, Chi had monthly meetings with each vendor. On a weekly basis, she’d have two to three calls with vendors. “This allowed me to check with them regularly about the API specifications, and about the launch,” says Chi.
Chi worked with engineers to build the vendor-facing API and shared the timeline with VPs. They released the API in multiple iterations:
- A minimum sellable product (MSP) version: lookup required documents, create a draft order (1 service type per country), submit a draft, and get order’s status for 50 countries.
- Allowing to add extra KYC documents in the draft order to serve the most complex 10 countries.
- Supporting bulk draft order: multiple service type, multiple countries for 1 consumer type.
Chi Learns Important Lessons After the API Launch
After launching, Chi learned that many of the larger customers that she had connected with weren’t ready to implement the new API. “After the launch, I discovered that our top customers had a different priority than using our APIs,” says Chi.
With API products, teams need to both identify the right functionality to offer and make the case for the customer to invest in the new technology. Chi did a great job of identifying the former, but missed the mark on the latter.
In retrospect, she wonders if this disconnect might have been a timing issue. She did her discovery in Q4, but the API didn’t launch until Q1. With the calendar year change, many of her largest clients were now focused on new company strategies. “My guess is that it was linked to vendors’ yearly company strategy (and therefore their product strategy),” explains Chi.
However, Chi was able to overcome this setback. She explains, “Big customers had different priorities, so I reached out to smaller ones. And because I got the core functionality right, this allowed me to drive adoption when things didn’t go as planned.”
Chi also monitored her company’s API traffic and noticed that some customers were adopting the API on their own. Since she had implemented and tested APIs in the past, she knew the pattern of how a developer tests an API, and when it would be the best time to reach out and convince them that her company’s API was easy to implement, clear, and well documented. “I reached out directly to them—of course with the agreement of our account manager team—and managed to drive adoption that way,” explains Chi.
Ultimately, the API was a successful product that brought in new revenue. Chi says one vendor even told her that their company managed to double their volume of orders while keeping the same number of members on their ops team (in other words, they could double their revenue without adding any new operations staff) thanks to this API.
Summing up her experience, Chi says, “We can and should do discovery, even for API products. The adoption of an API depends hugely on the strategy of our customers, so we need to make sure that we understand their business and the customers they are serving.”
Do you work on an API team that needs help getting started with discovery? Check out our comprehensive guides on what discovery is, on how to conduct effective interviews, and how to run high-quality assumption tests.
