Jobs to be done - Share a pain and gain for API platform teams, API developers and API consumers

Hey folks,

On the back of a great 2nd session of the API platform engineering fundamentals programme, we wanted to continue the discussion regarding pain points and outcomes for different teams connected to API platforms.

In the comments below, share 1 pain and 1 gain that you can think of regarding the 3 teams (You can pick 1 or more teams):

  • API platform team - internal team enabling API/app development
  • API/App developers - internal team developing applications/API products for consumption
  • API consumers - internal/external team discovering, consuming APIs/API products directly or using them to build their own applications

Pains => Identify unmet customer needs.What pain points do my customers have in common? What do they currently lack?

Gains => Determine customers’ desired outcomes. What is it we are helping customers do or helping them avoid?

Here is a little inspiration based on the workshop conducted last week:

I think I must have wrote this a couple of different ways… :joy:

When I am an app developer and working on a new endpoint
I want to test its functionality, performance, and security
so that I can make sure the new endpoint works with existing systems

Testing or debugging challenges (Lack of proper testing or sandbox environment) takes too long to spin up environment, not all jobs are running so you have to stop, kick off a job from the console, bad test data)
If there is no proper testing environment that mirrors production as best as possible, there is increased potential of introducing defects into the system and with external systems. For example in the fintech space, banking systems and payment rails

Having a proper environment to test provides

  • Less user disruptions
  • Compliance
  • More stable code released into production
  • Bonus: Dev Experience because new devs have a place to learn without exploring in production
1 Like

API Consumers:
1.API consumers have dependency on API developers who developed APIs. Any changes in API need to make sure changes made at consuming applications
2. API should be deployed and working so that API Consumers proceed on changes/development which need to make at consuming applications.
3.Integrate API into application

1.Good API Specification by API developer , API consumers able to integrate APIs very quickly.
2. Governance in place makes life easy for API Consumers

API Developers

  1. Creating API specification where multiple operations and functionality endpoints in APIs
    2.CICD update if any changes in Pipeline and which delays deployment process
    3.Integrating third party tool for security like JWT token creation/OAuth etc.
  2. Network connectivity/ Firewall issue dependency with Platform team
  3. Error handing, Logging
  4. API Response time
    1.Automation for CICD where test cases ,quality check makes life easy for API deployments.
    2.Stable API development platform creates API quickly
  5. API reusability

A bit late to the party and I’m not an API dev myself, but here’s a thought.

API Developers
When I develop an API for consumers to access
I want to ensure there is an authentication mechanism that is consistent with other APIs we publish
So that we ensure application security whilst delivering a single consistent developer experience

Pain(s): Without centralised platform guidance on approved authentication approaches, API developers will spend more time deciding what approach to take, and the result may be an inconsistent experience for API consumers across different APIs presented by the organisation.

Gain(s): A secure application. Faster delivery due to pre-existing authentication guidance. A consistent developer experience thanks to a single centralised standardised approach.

  • API platform team:
    • Pain: after acquisitions we end up with 2+ conflicting sets of API guidelines, managing and testing solutions
    • Gain: common set of rules and tools to be aligned with the overarching company goal of “one company, one team” while not being too disruptive to existing practices
  • API developers:
    • Pain: unclear what existing APIs we can leverage to avoid reinventing a wheel when adding new APIs
    • Gain: no duplication of business logic, less work maintaining APIs
  • API consumers:
    • Pain: unclear what are performance parameters of APIs and how can we manage the load
    • Gain: Be able to use proper APIs for desired load and be able to tweak parameters according to our preference (note: this is a specific to consumers who use on-premises installations)