books/The-API-Book
1
0
Fork 0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-01-05 10:20:22 +02:00
Code Issues Releases Activity

'Developing a product vision' chapter translated

Browse Source
This commit is contained in:
Sergey Konstantinov 2022-05-25 01:02:35 +03:00
parent 76bbdbf2f8
commit 64505e66a9
2 changed files with 26 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/en/drafts/04-Section III. The API Product/02.md
View File

@ -50,7 +50,7 @@ B2B services are a special case. As B2B Service providers benefit from offering
* API development plans are totally opaque to partners, and sometimes look just absurdly with obvious problems being neglected for years;
* technical support of external customers is financed on leftovers.
All those problems lead to having an external API that actually hurts the company's reputation, not improves it. In fact, you're providing a very bad service for a very critical and sceptical auditory. If you don't have a resource to develop the API as a product for external customers, better don't even start.
All those problems lead to having an external API that actually hurts the company's reputation, not improves it. In fact, you're providing a very bad service for a very critical and skeptical auditory. If you don't have a resource to develop the API as a product for external customers, better don't even start.
##### API = an advertisment site

32
src/en/drafts/04-Section III. The API Product/03.md
View File

@ -1,14 +1,32 @@
### Developing a Product Vision
The above-mentioned fragmentation of the API target audience, e.g. the ‘developers — business — end users’ triad, makes API product management quite a non-trivial problem. Yes, the basics are the same: find you auditory's needs and satisfy them; the problem is you product has several different auditories, and their interests sometimes diverge. The end users demand for an affordable cup of coffee does not automatically imply business demand for a coffee machine API.
The above-mentioned fragmentation of the API target audience, e.g. the ‘developers — business — end users’ triad, makes API product management quite a non-trivial problem. Yes, the basics are the same: find your auditory's needs and satisfy them; the problem is that your product has several different auditories, and their interests sometimes diverge. The end users' request for an affordable cup of coffee does not automatically imply business demand for a coffee machine API.
Generally speaking, the API product vision must include the same three elements:
* grasping how end users would like to have their problems solved;
* projecting how business would solve those problems if appropriate tools existed;
* understanding what technical solutions might exist and where lie the boundaries of their applicability.
* projecting how the business would solve those problems if appropriate tools existed;
* understanding what technical solutions might exist and where are the boundaries of their applicability.
On different markets and in different situations, the ‘weight’ of each element differs. If you're creating an API-first product for developers with no UI components, you might the skip end users problems analysis; and by contrast, if you're providing an API to extremely valuable functionality and you hold a close-to-monopolistic position on the market, you might actually never care about how developers love your software architecture or how convenient your interfaces are for them, as they simply have no other choice.
In different markets and different situations, the ‘weight’ of each element differs. If you're creating an API-first product for developers with no UI components, you might the skip end users' problems analysis; and, by contrast, if you're providing an API to extremely valuable functionality and you're holding a close-to-monopolistic position on the market, you might actually never care about how developers love your software architecture or how convenient your interfaces are for them, as they simply have no other choice.
In the majority of cases we still have to deal with two-step heuristics based on either technical capabilities or business demands:
* you might first form the vision how you might help business owners given the technical capabilities you have (heuristics step one); then, the general vision how your API will be used to satisfy end users' needs (heuristics step two);
* or, given your understanding of business owners' probleblems, you might make one heuristical ‘step right’ to outline future functionality for end users and one ‘step left’ to evaluate possible technical solutions.
In the majority of cases, we still have to deal with two-step heuristics based on either technical capabilities or business demands:
* you might first form the vision of how you might help business owners given the technical capabilities you have (heuristics step one); then, the general vision of how your API will be used to satisfy end users' needs (heuristics step two);
* or, given your understanding of business owners' problems, you might make one heuristical ‘step right’ to outline future functionality for end users and one ‘step left’ to evaluate possible technical solutions.
As both approaches are still heuristic, the API product vision is inevitably fuzzy, and it's rather normal: if you could have got a full and clear understanding of what end-user products might be developed on top of your API, you might have developed them on your own behalf, skipping intermediary agents. It is also important to keep in mind that many APIs pass the ‘terraforming’ stage (see the previous chapter) thus preparing the ground for new markets and new types of services — so your idealistic vision of a nearby future where delivering freshly brewed coffee by drones will be a norm of life is to be refined and clarified while new companies providing new kinds of services are coming to the market. (Which in its turn will make an impact on the monetization model: detalizing the countenance of the forthcoming will make your abstract KPIs and theoretical benefits of having an API more and more concrete.)
The same fuzziness should be kept in mind while making interviews and getting feedback. Software engineers will mainly report the problems they've got with the technical integrations, and rarely speak of business-related issues; meanwhile, business owners care little about code-writing inconvenience. Both will have some knowledge regarding the end users problems, but it's usually limited to the market segment the partner operates on.
If you do have an access to end users actions monitoring (see the ‘API KPIs’ chapter), then you might try to analyze the typical user behavior through these logs, and understand how users interact with the partners' applications. But you will need to make this analysis on a per-application basis, and try to clusterize the most common scenarios.
#### Checking product hypotheses
Apart from the general complexity of formulating the product vision, there are also tactical issues with checking product hypotheses. ‘The Holy Grail’ of product management — that is, creating a cheap (in terms of resource spent) minimal viable product (MVP) — is normally unavailable for an API product manager. The thing is that you can't easily *test* the solution even if you managed to develop an API MVP: to do so, partners are to *develop some code*, e.g. invest their money; and if the outcome of the experiment is negative (e.g. the further development looks unpromising), this money will be wasted. Of course, partners will be a little bit skeptical towards such proposals. Thus a ‘cheap’ MVP should include either the compensation for partners' expenses or the budget to develop a reference implementation (e.g. a complementary application must be developed alongside the API MVP).
You might partially solve the problem by making some third-party company release the MVP (for example, in a form of an open source module published in some developer's personal repository) but then you will struggle with hypothesis validation issues as such modules might easily go unnoticed.
Another option for checking conjectures is recruiting an API provider company's services developers if they exist. Internal customers are usually much more loyal towards spending some effort to check a hypothesis, and it's much easier to negotiate MVP curtailing or freezing with them. The problem is that you can check only those ideas that are relevant to internal services needs.
Generally speaking, the ‘eat your own dogfood’ concept applied to APIs means that the product team should have their own test applications (i.e. ‘pet project’) on top of the APIs. Given the complexity of developing such applications, it makes sense to encourage having them, e.g. giving free API quotas to team members and providing sufficient free computational resources.
Such pet projects are also valuable because of the unique experience they allow to gain: everyone might try a new role. Developers will learn product managers' typical problems: it's not enough to write a fine code, you also need to know your customer, understand their demands, formulate an attractive concept, and communicate it. In their turn, product managers will get some understanding of how exactly easy or hard is to render their product vision into life, and what problems the implementation will bring. Finally, both will benefit from taking a fresh look at the API documentation and putting themselves in the shoes of a developer who had heard about the API product for the first time and is now struggling with grasping the basics.