john gibbon
  • Bio
  • Stanford Class
  • Product Mgt
  • Product Dev
  • Career Resources
  • Blog
  • Strategy

Agentic AI, Partnerships, & APIs: Boom or Bust?

6/2/2025

0 Comments

 
Picture
Are you leveraging APIs to 
  • Provide client services?
  • Build partner ecosystems?
  • Power AI agents?
If not, it's time to start.

The era of agentic AI is here. As these autonomous agents rely on APIs, we are seeing a surge in API usage and a new wave of API-driven partner ecosystems.    

This means now's your chance to deliver more value to your customers and grow API revenue-but it also means your APIs may quickly become obsolete. 
​

Here's how to sell API services in the agentic AI era—​and how to prepare for what's next. 

Picture

1000x API Growth

As mentioned in my recent blog post on agentic AI, client agents act on behalf of a human user. They contain API calls to other services such as "make a payment" or "get invoice status." 

(Increasingly these API services are contained inside service agents powered by MCP servers. Anthropic's Model Context Protocol (MCP) specifies the structure for how agents call one another to request services. When agents are built using an agentic framework, such as LangGraph or CrewAI; the framework enables agents to call these MCP servers.)


The more agents we build, the more API services they'll consume—​whether directly or  through MCP servers. This is why the API services provided by software vendors are even more important in the era of agentic AI.

As Aaron Levie CEO of Box said, "the de facto model of software integrations in AI is one primary AI Agent interacting with the APIs of another system. This is a great model, and we will see 1,000X growth of API usage like this in the future."  ​

Picture

Selling APIs to Agents

As we accelerate into the agentic AI era, API service vendors (which all software companies should be) need to 
craft strategies for API products to be more easily utilized by Large Language Models (LLMs) and agents. Like many other companies, Stripe has implemented an “Agent SDK” which natively supports agentic frameworks.

​These SDKs often expose higher-level capabilities more easily used by an agent-for example, a single function like "clients_last_actions()" instead of multiple API calls. They could also provide natural language "context" which is useful for an LLM; for example "this function provides the most recent client actions such as support calls, product inquiries, or payments."

Picture

Using Agents to Sell APIs

Companies can also use LLMs to make their APIs easier for developers to use  - whether they are building agents or traditional applications. As is becoming increasingly true for support across a variety of industries, software companies who are providing APIs to their partners can create an AI support agent. LLMs power these agents which answer developer questions and provide real-time support.   Companies such as VoPay have created developer support agents by pre-populating an instance of ChatGPT with FAQs, code samples, and other documentation.

Of course, it doesn't stop there. Software companies can use LLMs to help generate code snippets or even most of a working application tailored to the developer's needs. Stripe has an AI Dev assistant and Google Cloud has Gemini Code Assist which integrates into IDEs and provides not only chat-based assistance for developers using their APIs but also contextual code completion and even code generation.​

Picture

Partner Ecosystems: More Revenue, More Client Offerings

If you are selling API-based services you are providing them to developers or really other companies which means you are building your partner application ecosystem.   Not only does this generate more revenue, but it also expands the offerings available to your clients.  Look at all the applications available on Salesforce's AppExchange or SAP Concur's App Center (and I happened to have worked on both of these).  

With the boom in agentic AI and its need for APIs, the potential growth for your partner program is accelerating.  As I have written about in the past, you need to consider "How to Become a Platform Company", the "what" and the "why" of becoming a platform company, and how platform and partnership programs grow your company.  Further, as I wrote about in "SaaS Partnership"; software companies need to distinguish between different type of partnerships and partnership business models; and what organizations and functions are required to grow partner revenue. 

However in order to survive and thrive, you not only must consider how you are selling your APIs to partners; but also what type of APIs or really services you are selling. ​Otherwise you won't fulfill the potential (and see the direct and indirect revenue growth) of your partner ecosystem.



Picture
​
UI-Driven Agents 
​

Today agents will be easier to build and more reliable if they engage with services that provide a explicit contract about how they behave, an API.  However some agents are being designed to watch users work and mimic their actions. This is a very powerful paradigm as it will augment human work by doing many of the repetitive tasks we do daily. Vendors providing "agentic robotic process automation (RPA)" or "LLM-enhanced process agents" include RPA companies such as UiPath and Automation Anywhere. 

These agents aren't using APIs because they are acting like a human user and interacting with a software company's traditional application graphical user interfaces (UI).  UIs change and their usage isn't always clear (even to us humans), but as agents evolve they will be more capable of navigating a traditional software UI. 

Since these type of agents don't use APIs, so this is one way that agents may render your APIs obsolete. 

​

Picture

From API Calls to Conversations

However the most effective and impactful agents will continue to use APIs. Although as vendors' services start becoming more agentic; traditional JSON formatted APIs may give way to more conversational or agent-native interfaces. 

Also, as mentioned in my earlier blog, the revolution will take another leap when Agent-to-Agent communication becomes more prevalent.  This will fuel a further shift towards conversational interfaces. 

Google's new Agent2Agent protocol prescribes agent-to-agent communication (A2A) to use JSON-formatted messages.  These messages can trigger underlying services that are either traditional JSON-based APIs or natural language-based interfaces. 


As the providers and the consumers of APIs become increasingly agentic, these powerful programs will increasingly be using their natural language interfaces for their interactions. This is especially true with A2A communication which enables more sophisticated and powerful capabilities.

=> Will agents and agent-to-agent communication make today's application APIs obsolete?

=> How are you evolving your API services for the agentic AI era? 


(Views are my own and do not represent those of any current or former employer.)​

0 Comments

You Think AI Agents Are Disruptive; Wait until They Talk to Each Other

5/10/2025

0 Comments

 
Picture

If you sell—or rely on—software, you need to know how agentic AI is already reshaping the design and business of software. And this is only the beginning; when agents start talking to each other, both your company and your career will need to evolve to stay relevant.​

​
AGENTIC AI WILL CHANGE THE DESIGN AND BUSINESS OF SOFTWARE


AI-based agents are autonomous systems capable of dynamically adapting to requests by using large language models (LLMs). They can carry out complex, multi-step processes with little or no human intervention.

​
💸 Pricing Shift: Per-user -> Per-transaction -> Per-Outcome
Picture
More enterprise software applications will shift from a per-user to a per-transaction pricing model. Pricing will be based on transactions or tasks completed such as APIs called, expense reports processed, or marketing emails sent because one agent can do the work of many human users. With the advent of agents, the business of software may change even further as companies "hire agents" much like they hire human workers to generate specific business value. Agents could deliver outcomes such as leads from marketing emails or savings from automating customer onboarding. (For more see my previous blog on SaaS pricing.)

Previously a software vendor was limited by the number of seats or end users it could enable. However, as Aaron Levie CEO of Box said, “AI Agents provide another vector of growth for software by enabling companies to essentially buy 'work' from their software vendor. And because this work is elastic, enterprises can throw AI Agents at both large and small problems in the business alike — like, reviewing a batch of contracts, qualifying a lead, transcribing a doctor visit, writing lines of code."  Or as Yoko Li from A16Z succinctly said "The market is growing so much bigger because there are use cases we haven't even thought about yet." 


​
🛠️ Design Shift: Graphical -> Conversational UX

Picture
Users won't click ten screens; they'll just say,  "pay all invoices that are due tomorrow", with a possible caveat "but confirm with me first." These type of agents, which act on behalf of a human user, are called client agents. Designers and developers will shift focus from workflow optimization—which agents will handle—to defining agent prompts, rules, and data structures that encapsulate industry knowledge and deliver distinct value.

In many applications the UX will be a mix of traditional graphical UI and conversational agents. This was my experience when building a simple agentic AI app using Replit.

More interesting, however, is when an agent is designed to use multiple systems - eliminating the need for humans to navigate between separate applications. For example a user can request an agent to "book a flight to get me to the conference I am going to next week." The agent would interact with a calendar app, a travel booking site, and a payment system. If this type of use case requires calling and coordinating responses between multiple agents, such as date and time availability,  this agent would be considered an orchestration agent.
​

Picture

🤝 AN EVEN BIGGER SHIFT: AGENT-TO-AGENT COMMUNICATION 

Today, agents respond to human prompts. Tomorrow, the “user” could be another agent. 
  The Wall Street Journal (Steve Rosenbush 3May2025) says that companies should start planning for this next stage of AI, the orchestration of multiple agents across their business. It reported that Accenture has more than 50 multiagent systems today for a range of industries and markets. Aaron Levie says agent-to-agent communication will be the biggest unlock of AI. 
​
Orchestration agents typically operate within a predefined workflow involving various other agents.  What if agent interactions are not constrained by a specific workflow? 
Agent-to-agent communication will enable software to automate and solve problems in novel ways that we have yet to consider.

When the World Wide Web first debuted, it was static or read-only. Most people thought what we now call Web 1.0 could possibly replace magazines or libraries. At the time few people considered its evolution to Web 2.0 or the read-write web which delivers dynamic content, social media, and business applications. Even fewer could have imagined a semantic and de-centralized Web 3.0.

As we evolve from predictive AI to also using generative AI, we are still optimizing the ways we solve problems. This is even more true with agentic AI especially as it starts including agent-to-agent communication. 
 
=>What are new approaches we aren't yet considering with this powerful new paradigm?


What business problems may be solved more effectively but in a manner unfamiliar to humans when we start building agents which aren't design to act on behalf of a human but to communicate and coordinate with other agents?  Real-time logistics involving hundreds of suppliers and dozens of currencies during a global crisis? Corporate strategies? Peace treaties?  Building more powerful agents? 

Picture

Agent Taxonomy

Service agents provide specific capabilities from a system to another agent. It might represent an API call to retrieve all sales opportunities for the month of May in a specific region. Client agents call service agents and provide additional capabilities such as using an LLM to understand a request and provide analysis: "give me all sales opportunities for the month which are similar to other opportunities which ultimately turned into sales". An orchestration can go further, combining multiple sources and providing richer capabilities "return sales opportunities which will likely turn into sales, and (looking at the company's ERP system) ultimately a successful, profitable customer." An earlier example - "Pay all bills due tomorrow, but confirm with me first" - becomes even more useful with a smarter caveat "but confirm with me first if after looking at my bank account and calculating my projected cashflow, you think a payment might cause future cashflow issues." 
There are also monitoring agents which are built to observe and audit, especially important in regulated environments. 
​

Picture
A2A Impact
​

A2A communication allows for even more sophisticated orchestration agents as it enables back and forth negotiation and evolving plans between client or orchestration agents. For example two systems defining what a "successful" customer is; or better, a buying agent and a selling agent negotiating a sale and making trade-offs based on parameters established by human users.


Recently I heard Miku Jha talk about Google's new Agent2Agent protocol. While there is some discussion about this, Google's A2A protocol complements Anthropic's MCP protocol which is the standard to connect LLMs with data, resources, and tools. A2A focuses on a different problem, agents communicating with other agents but not as tools or end points. It enables back and forth negotiation between different autonomous identities. To paraphrase Ali Arsanjani's Medium Post, Anthropic’s MCP tells an agent what another agent can do; Google’s A2A standardizes how they negotiate to do it.

Much like APIs advertise their capabilities with MCP; agents advertise their capabilities with a JSON format "Agent Card". The communication between agents is oriented towards task completion; and agents can send each other messages around context, replies, artifacts or user instructions.


At CES 2025, NVIDIA CEO Jensen Huang said, "In the future, these AI agents are essentially a digital workforce that will be working alongside your employees." 

=> What type of business problems may be solved more effectively by agents than humans when we start building agents designed to talk with each other?   

=> What does that mean for your company?  Your career?​ 

=>Tell me what you think below.  Let’s talk



(Views are my own and do not represent those of any current or former employer.)
0 Comments

To Know a Person

1/8/2024

0 Comments

 
Picture
As I try to become a better listener, the book that has been most helpful is  "How to Know a Person" by David Brooks. The top insights that I took from this book are:

One fundamental skill that lies at the heart of any healthy person is the ability to see someone else deeply and make them feel seen - to accurately know another person, to let them feel valued, heard, and understood. Life goes a lot better if you can see things from other people's points of view, as well as your own.

Diminishers make people feel small and unseen with their egotism, anxiety, naive realism, objectivism (detached and dispassionate), essentialism (making generalizations), and their propensity towards the lesser-minds problem (like many people, they think that they are more complicated and deeper thinkers than others).

Illuminators are practiced in the craft of understanding others, they have a persistent curiosity about other people. They show tenderness, receptivity, active curiosity, affection, generosity, and a holistic attitude (knowing people have a spectrum of strengths and weaknesses). 

A diminisher makes you think he is interesting; an illuminiator makes you think you are interesting. One illuminator once asked the author about his ultimate goals (what does he want to offer the world?), his skills (what is he doing when you feel most alive?), and his schedule (how does he fill his day? and how well that is aligned with the first two?) 

Tips on how to pay attention to a person or how to accompany a person:
  • be aware of the other person's timetable, playfulness, & other-centeredness 
  • treat attention as an on/off switch not a dimmer
  • be a loud listener 
  • favor familiarity (people don't favor the unfamiliar)
  • make other people the actors, not the witnesses
  • don't fear the pause
  • do the looping (repeat what people say)
  • assist people in their creation (the midwife model)
  • keep the gem statement at the center
  • find the disagreement under the disagreement
  • don't be a topper 

Wise people possess a compassionate understanding of other people, they don't necessarily possess information. Wise people don’t tell us what to do; they start by witnessing our story; more like coaches than philosopher kings. 

The author Studs Terkel wrote, "Listen, listen, listen, listen, and if you do people will talk. They always talk. Why? Because no one has ever listened to them before in all their lives. Perhaps they've not ever even listened to themselves." 

If you want to thrive in the age of AI, you better become exceptionally good at connecting with others

We are generally only 20% accurate when perceiving what others are thinking in our first conversation with them; and that only raises to 35% accurate with close friends and family. For people who are very good it is high as 55%, but those of us who aren't very good still think we are very good at reading other people.

“Moral formation” is about helping people learn how to restrain their selfishness and incline their heart to care more about others. It’s also about helping people find a purpose, so their life has stability, direction, and meaning. It’s about teaching the basic social and emotional skills so you can be kind and considerate to the people around you.

Before entering into any hard conversation, it’s important to think about conditions before you think about content. Also, for members of dominant or majority groups, there’s usually little or no gap between how others see you and how you see yourself. For people from marginalized or historically oppressed groups, there’s usually a chasm between who you are and how you are perceived.

Conversation take place on two levels: the official conversation (words about the nominal topic at hand) and the actual conversation (ebb and flow of underlying emotions).  In a conversation consider its frame: what is the purpose of the conversation and what are the goals. 

Bad questions evaluate (I'm about to judge you) and are closed (limit how they can be answered). Sometimes a broad, dumb question is better than a smart question, especially one meant to display how well-informed you are. When you are asking a good question, you are adopting a posture of humility. You're confessing that you don't know and you want to learn. You are honoring a person.

Big questions interrupt daily routines:
  • What crossroads are you at?
  • What would you do if you aren't afraid?
  • If you died tonight, what would you regret not doing?
  • If we were meet a year from now, what will we be celebrating?
  • If the next five years is a chapter in your life, what is that chapter about?
  • Can you be yourself where you are and still fit in?

Questions about the positive side of life include:
  • Tell me about a time you adapted to change
  • What's working really well in your life?
  • What are you most self-confident about?
  • Which of your five sense is strongest?
  • Have you ever been solitary without feeling lonely?
  • What has become clearer to you as you have been aged?

The real act of building a friendship is disagreeing without poisoning a relationship, releasing vulnerability at an appropriate pace, being a good listener, knowing how to end a conversation gracefully, knowing hot to ask for and offer forgiveness, knowing how to let someone down without breaking their heart.

It’s not only the epic acts of heroism and altruism that define a person’s character; it’s the everyday acts of encounter. It is the simple capacity to make another person feel seen and understood—that hard but essential skill that makes a person a treasured co-worker, citizen, lover, spouse, and friend.


0 Comments

SaaS Partnerships

2/1/2023

1 Comment

 
Overview of SaaS Partnerships
​from when I worked at enterprise Software as a Service companies


Technology Providers: Supply capabilities used in SaaSCo's offering
Provide services required for a specific market or product
  • Database technology providers
  • Hosting / cloud providers
  • Information / data providers

Owned by Technology and Operations organizations
Non exclusive relationships


Service Providers: Implementation, support, etc. for a specific market  
  • System Integrators (SI) for a specific region or for a specific software package
  • Support services for a given market (such as a language / country where SaaSCo's in-house support not available)
  • MSP - managed service providers (overlap with technology providers as could be outsourced IT)

Owned by the department at SaaSCo that usually provides this service such as implementation or support team

Relying on expertise in market or product type so exclusivity unlikely unless referral or resell involved 


Go-to-Market Referral or Distribution Resell Channel Partners:
Assist in selling SaaSCo's offering in given market (region or segment) or channel
  • Affiliate marketing
  • Referral partner
  • (Value Added) Resellers
  • Online marketplaces

Owned by Marketing and Sales teams; and specifically Channel Sales & Marketing

Most likely involves exclusivity for SaaSCo’s market


Product Partners (ISV - Independent Software Vendor)
Enhance client offering 
  • Provides key capability or offering that is needed to help sell SaaSCo’s offering for given market or segment
  • Helps create an ecosystem which is a broader value proposition to the client​

For one SaaS company approximately 3/4 of clients said presence of a partner ecosystem and the promise that a wider base of solutions than just SaaSCo's solution was a principle reason they picked the (higher priced) SaaSCo offering.  According to CrossBeam, one company had 34% higher annual contract value (ACV) on deals done with product partners.

Owned by Product organization
Exclusivity in resell model but less likely in referral model


Although!  Often there are overlaps across these categories
  • System Integrators (especially Global System Integrator GSIs) can also refer or resell products which they integrate. 
  • Product partners can also be referral partners encouraging clients who do not already have SaaSCo’s product to use it as it makes their offering more compelling and valuable. In this case the channel sales team will own or at least dictate the terms of the referral agreement with the Product Partner, even if the product partnership team is the lead.
  • Distribution partners can be white label partners integrating SaaSCo's solution with their own offering; but partnership must be enabled in conjunction with product teams market offering strategy.


Picture
Two Distinct Product Partnership Business Models for SaaS Companies

There is a big gap between these two product partnership models because in the resell model SaaSCo owns the revenue and the risk! 

Referral
Enables solutions and sales for SaaSCo especially with regional / vertical opportunities; drives some revenue
  • Percentage (with minimums) of what partner charges for a “connector” to the SaaS company’s services or data
  • and / or a portion (maybe roughly 1/4) of the total offering that the partner charges - depending on how much SaaSCo needs the client's solution to more effectively sell their own (for example a partner's compliance offering that is required to sell SaaSCo's offering in a certain market). 
  • Also a one-time referral fee for a partner offering purchased by SaaSCo clients.

Access to basic marketing mostly focused around SaaSCo’s marketplace or “App Store” listing

Limited sales support into SaaSCo sales organization and client base

Minimum support other than integration

No/minimal influence on partner's product development roadmap

Premium Referral program could involve additional fees from partner for specific additional marketing and sales opportunities

Minimum risk vetting since not on SaaSCo paper (not a SaaS company contract); although realizing SaaSCo brand still takes some risk if there is referral


Resell
New product offering for SaaSCo; driving significant revenue
  • Negotiated percentage of partner core offering list price (very roughly in 50% range although this could vary widely depending on which party is responsible for which activities - such as support; and which party more needs the other party - who has the power!)
  • Aspects of deal may include certain exclusivity (regions, accounts), sales channel conflict avoidance strategies such as double commission, list price discounts, and SaaSCo committed volumes.

Negotiated co-marketing; and SaaSCo marketing like other SaaSCo’s products.

Sold like other SaaSCo product with customer / market restrictions and minimum volumes negotiated as part of deal.

Support negotiated but generally Level 1 and Level 2 support by SaaSCo and detailed Level 3 support by partner.

Influence on partner's product development roadmap potentially negotiated as part of deal.

Premium resell may be white labelled where SaaSCo has exclusivity across larger markets and owns more of partner roadmap.

Since on SaaSCo paper, need to do full risk review and create processes across entire operations between partner and SaaSCo

As a reminder! 

Partners want access to data and functionality and access to brand, marketing, sales teams, and clients.


​Platform & Product Partnerships Organization and Functions

Product and Partner Development
  • Product Management: Building business models and APIs and other product offerings needed to deliver on identified partner enabled use cases. Working with Technology organization and other product managers.
  • Business Development: Recruitment and contract negotiation of targeted partners and categories. Working with Corporate business development and corporate partnerships. Can also work with corporate M&A group as a partnership pipeline is being created: referral partners are good candidates to become resell partners; and resell partners are good candidates for potential acquisition.
  • Technical Enablement:​ Helping partners build the identified integrations and applications. Working with global support.

Partner Success and Partner Revenue
  • Marketing: Helping clients, prospects, and sales teams understand the value proposition of partner solutions. Working with corporate and regional marketing.
  • Alliance and Sales: Partner account management; and advocating for partner solutions to be sold to specific customers and to be integrated with specific SaaSCo prospect opportunities. Working with regional sales.
  • Services: Application implementations and partner customer support; also billing and revenue tracking. Working with global support and operations
1 Comment

Empowered

7/16/2022

0 Comments

 
Picture
  
Recently I heard Marty Cagan speak as part of the McKinsey Product Academy Series. In the past Marty has spoken at my class and I have reviewed his book Inspired, my favorite book on product management.
 
Therefore I thought it was finally time for me to read the book he wrote with Chris Jones in 2021, Empowered. It can easily be used as a reference book when considering any one of a range of topics about how companies create extraordinary software products. However there are a few central themes which I thought would be helpful to describe here.
 
Two of the main messages around creating empowered product teams are:
  • Give product teams problems to solve, rather than features to build. Empower them to solve those problems in the best way they see fit.
  • Leadership is about recognizing that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge. - Bill Campbell
 
Feature vs Empowered Teams (solve customer problems, achieve outcomes):
     A central theme in the book is the distinction between feature product teams and empowered product teams. A feature team implements features and projects (output), and as such isn’t empowered or held accountable to results. In contrast, an empowered team is accountable for solving a customer problem or achieving a specific outcome, and is empowered to do so in the best way they see fit.   

Difference Between Strongest Product Companies and the Rest 

1. Role of Technology (it is the business, not an expense):
     So many companies still have the old IT mindset when it comes to technology. It's viewed as a necessary cost rather than the core business enabler it needs to be. The people who work on the technology teams are literally there “to serve the business." In these scenarios, the product and technology teams are disconnected from the real customers—in fact, they're encouraged to think of their stakeholders as their customers. For strong product companies, technology is not an expense, it is the business.
 
2. Role of Product Leaders (coaching, strategy, managing to results, deep business and product knowledge):
     Most product leaders are responsible for staffing the in-house feature factory, and keeping the trains running on time. The best product leaders are staffing and coaching product teams, creating product strategy, putting strategy into action, and managing to results
  • You need to be very specific when identifying the most important business problems a product team should solve. 
  • Your role as a leader is in helping everyone on the team achieve the competence necessary to solve those problems.
       Product Leaders need to have a deep business and product knowledge (and frequent customer interactions)
  • Data (how the product is actually used)
  • Industry and domain knowledge
  • Business and company knowledge
  • Product operational knowledge (how the product actually works)
  • (most importantly) Users & customer knowledge
     Cagan recommends a minimum of three, one‐hour customer interactions each week. During weekly one-on-ones he likes asking about these customer interactions to see what the product person has learned. He also encourages the product person to share stories of what they experienced during these visits, and then to share these stories widely around the company. One reason for this is for the product person to establish their reputation as someone who has a deep and personal knowledge of the company's users and customers.

3. The purpose of product teams (product managers, product designers, and engineers)
     Consistent with the central theme of the book, Cagan believes that in strong product companies teams are given problems to solve, rather than features to build, and most importantly they are empowered to solve those problems in the best way they see fit and are then held accountable to the results.


Picture

​Importance of Product Vision, Strategy, & Discovery
In empowered product teams:
  • Product vision describes the future we are trying that improves the lives of our customers 
  • Product strategy helps us decide what problems to solve
  • Product discovery helps us figure out the tactics that can actually solve the problems

Product vision keeps us focused on the customer and serves as a North Star 
     It provides the product organization with a common understanding of what we are hoping to accomplish together. A good product vision inspires ordinary people to create extraordinary products. A good product vision provides us with meaningful work.
     When a company has grown to the point where there are multiple product teams—supporting many customers with their constant needs. It is very easy for each product team to get caught up in their own problems and their own work, losing sight of the overarching goal. The product vision represents the common goal and constantly reminds us of the larger purpose.
 
Product Strategy: Based on insights, it is how we make the product vision a reality while meeting the needs of the company as we go
     While product strategy starts with focus, it then depends on insights.  Insights come only after you spend hours studying your data, your customers, the enabling technologies, and your industry. Insights can come from anyone or anywhere – salesperson, new technology, random comment from a customer, or an academic paper. They might pertain to the dynamics of our business, our capabilities, new enabling technologies, the competitive landscape, how the market is evolving, or our customers. The foundation for significant insights is the strategic context found in the company objectives, the company scorecard/dashboard, and the product vision. Insights are both quantitative and qualitative insights; and they need to be shared and communicated.
     Many companies have a stakeholder‐driven roadmap process, where they basically are trying to find a way to “fairly” divide up the engineering capacity across the different business stakeholders.  But by not picking your battles and focusing on the few truly critical problems, most of the product team's work  does not make an impact.
 
Product Discovery finds product market fit by considering value, usability, feasibility, viability (as discussed in Inspired) 
  • Value – will users buy and use it (Product Mgr)
  • Usability – can they figure out how to use it (UX)
  • Feasibility – can we build it (tech arch)
  • Viability – part of our overall business 
(Product Market Fit is the essential component for any successful product.)
     Discovery can’t be done by stakeholders, customers and prospects; they don’t know what is possible and they don’t know what solutions work
     Often customers try to discuss solutions but they really are discussing problems. It is natural for a prospect to try to dictate requirements for features, but a product manager's job is to work to understand their underlying issues and constraints, and then work collaboratively with your prospective customers to determine if there's a general solution that will meet their needs. This form of collaboration is at the heart of the customer discovery program technique mentioned above and discussed in Inspired.
 
​
Picture
Marty (upper right) and the Silicon Valley Product Group look like a collaborative team that knows how to evangelize 

Collaborative Product Teams
     Your company is probably accustomed to feature teams that exist very clearly to serve the business, and it can be difficult to replace them with empowered product teams that exist to serve our customers in ways that work for the business. Your product organization is moving from a subservient model to a collaborative model.
    Part of this is done by product leaders establishing a direct relationship with the CEO (or general manager in a large company) and the other key executives (sales, marketing, service, finance, legal, business development.) The basis of this relationship is for the executives to believe that the product leaders have a deep understanding of the business and are committed to ensuring that the solutions provided will work for the various aspects of the business. This should be table stakes for the product leaders. Beyond that, there are three aspects the product leaders will be judged on: business results, product strategy, product teams
 
All of this may be Tougher in Larger Companies (Evangelism will help)
     Personally, I think Marty’s suggestions seem to be better suited or maybe more straightforward to implement in small companies with more greenfield products. However, Marty does provide at least one key to being a strong (empowered) product leader in a medium-sized to large‐sized company, evangelism.  Evangelism in this context means marketing to your own organization (e.g., product marketing, marketing, and sales). Some techniques used to help communicate the value of your product or what you’re proposing to your product teams, executives, key stakeholders, and investors include
  • using prototypes
  • sharing the customer pain
  • explaining the product vision
  • sharing your learnings
  • giving great demos
  • sharing the credit
  • detailing the market opportunity
  • showing your enthusiasm for your product
 
 
Check out more information from Marty Cagan at SVPG.
0 Comments

Bitcoin, Blockchains, DeFi, and DAOs:  A Few Central Concepts

3/5/2022

0 Comments

 
Or John Doesn’t Know S**t about Crypto:
a mostly accurate overview with only a few misleading generalizations
​
It was great presenting to the Notre Dame Tech Forum on a few central crypto concepts:
  1. What is money?
  2. So why was Bitcoin invented?  
  3. Wait, isn’t this all just a scam?
  4. Blockchains and Distributed Apps –  powering the future !?
  5. Distributed Finance – get a loan without talking to a bank
  6. Enterprise Blockchains – so companies / problems I’ve heard use this?
  7. Distributed Autonomous Organizations – the future of human society !?
​
​Below is the presentation and here is the recording of the event along with the presentation.
​
0 Comments

DeFi: Blockchain and Smart Contract Based Financial Markets

1/4/2022

1 Comment

 
My favorite overview of DeFi that I have read so far is Decentralized Finance: On Blockchain- and Smart Contract-Based Financial Markets written by Fabian Schar and published by the St. Louis Fed. (Although a few things seem a bit out-of-date since it is a year old and Whiteboard Crypto on YouTube is a tad bit more accessible.) 

Here are a few of my takeaways from reading this article.

DeFi replicates existing financial services in a more open and transparent way. In particular, DeFi does not rely on intermediaries and centralized institutions. Instead, it is a blockchain-based financial infrastructure with open protocols and decentralized applications (DApps). Besides a rich instruction set DApps or smart contracts can also acts as custodian for crypto assets.
 
(DApps or smart contract theoretically could be any arbitrary computer program since they run on Turing complete blockchains (all but Bitcoin); although they are very inefficient. The ability to run more complex smart contracts is one of the biggest differences between Bitcoin and Ethereum block chains.  Blockchains like Solana are designed to address the inefficiency or scalability problems of blockchains like Ethereum).   
 
Native protocol crypto assets (BTC, ETH or cryptocurrencies ) are used to operate the blockchain. 
 
Crypto assets that are tokens are units of value that blockchain based organizations or projects develop on top of existing block chain networks. Token standards include ERC-20 for tokens which can interoperate with Ethereum's ecosystem of decentralized apps. ERC-720 are non-fungible tokens (NFTs) used to tokenize ownership of any arbitrary data. For example they can be the digital representation of a physical object such as a piece of art.
 
This means that tokens can serve a variety of purposes: including governance tokens for decentralized autonomous organizations (DAO), tokens that allow the holder to perform specific actions in a smart contract, tokens that resemble shares or bonds, and even synthetic tokens that can track the price of any real-world asset.
Picture
As you can see above, besides settlement layer (blockchain native protocols) and asset layer (including tokens) there is a protocol layer containing decentralized exchanges used by other DApps, an application layer, and aggregation layer to connect several applications and protocols

In decentralized exchanges, users do not need to deposit their funds which is the case with centralized exchange. Instead, users maintain control of their assets until the trade is executed. Trade execution happens atomically through a smart contract, meaning that both sides of the trade are performed in one indivisible transaction, mitigating the counterparty credit risk. Depending on the exact implementation, the smart contract may assume additional roles, effectively making many intermediaries such as escrow services and central counterparty clearing houses (CCPs) obsolete.
           
​Decentralized lending platforms and loans are an essential part of the DeFi ecosystem. Defi loans do not need to rely on trusted relationships via one of two methods. One method is credit being provided under the condition that the loan must be repaid atomically, meaning that the borrower receives the funds, uses, and repays them—all within the same blockchain transaction. A second way is loans can be fully secured with collateral. The collateral is locked in a smart contract and only released once the debt is repaid.

One type of collateralized loan platforms allow the user to create collateralized debt positions; in other words the user gets new tokens back by collateral locked in smart contract (or in the example below, just USD). For example MakerDAO is a decentralized protocol that is used to issue the USD-pegged Dai stablecoin.  First, the user deposits ETH in a smart contract classified as a collateralized debt position (CDP) (or vault). Subsequently, they call a contract function to create and withdraw a certain number of Dai and thereby lock the collateral. 
Picture
There are also collateralized debt markets. Instead of creating new tokens, it is also possible to borrow existing cryptoassets from someone else - either pooled (subject to supply and demand) or P2P (person to person).

Decentralized derivatives are tokens that derive their value from an underlying asset's performance (tokenized versions of stocks, precious metals, alternative crypto assets), the outcome of an event, or the development of any other observable variable.
 
For on-chain asset management whenever someone invests in an on-chain fund, the corresponding smart contract issues fund tokens and transfers them to the investor's account. These tokens represent partial ownership of the fund and allow token holders to redeem or liquidate their share of the assets.
 
In summary, the opportunities of DeFi are based on
  • Efficiencies: While much of the traditional financial system is trust based and dependent on centralized institutions, DeFi replaces some of these trust requirements with smart contracts. The contracts can assume the roles of custodians, escrow agents, and CCPs.
  • Transparency: All transactions are publicly observable and smart contract code can be analyzed on chain.
  • Accessibility: Theoretically open to anyone, the risk of discrimination is almost inexistent due to lack of identities.
  • Composability: Any two or more pieces can be integrated, forked, or rehashed to create something entirely new. Anything that has been created before can be used by an individual or by other smart contracts. This flexibility allows for an ever-expanding range of possibilities and unprecedented interest in open financial engineering.
 
The risks include:
  • Smart contract execution: Users have to be aware that the protocol is only as secure as the smart contracts underlying it; leaving it vulnerable to coding errors or exploration (by analyzing the transparent underlying code).  Most users won't be able to read contract code, understand its potential security concerns, or understand the data payload - and there is no central administration to adjudicate issues or risks (although there are insurance and other similar services).
  • Operational security: While blockchains are permissionless and not reliant on a central government or authority; ironically governance and some control is often held by a small groups of people (usually the project's core team) and smart contracts are reliant on external data.
  • Illicit activity: Pseudonymity can be abused by actors with dishonest intentions. Regulators can (or should) regulate a decentralized infrastructure, there are two areas that deserve special attention, namely, fiat on- and off-ramps and the decentralization theater.
  • Scalability: (This is why I am intrigued since by Solana which is built with native parallelism; Solana scalability >> Ethereum scalability)
 
DeFi has unleashed a wave of innovation. On the one hand, developers are using smart contracts and the decentralized settlement layer to create trustless versions of traditional financial instruments. On the other hand, they are creating entirely new financial instruments that could not be realized without the underlying public blockchain. Atomic swaps, autonomous liquidity pools, decentralized stablecoins, and flash loans are just a few of many examples that show the great potential of this ecosystem.

1 Comment

John Doesn't Know S**t about Growing a SaaS Business

7/18/2021

0 Comments

 
It was great presenting to the Notre Dame Tech Forum. 
Everyone got to tell me:

What Do I Have Wrong about
What You Need to Get Right
To Grow a Company?

The five things I think you need to get right include:
​
  • Find Product Market Fit  (inspired by @ Marc Andreessen)
  • Optimize Marketing / Sales Funnel 
  • Create Customer Success  (inspired by Nick Mehta)
  • Build Company Culture (inspired by Dan Coyle) 
  • Use KPIs for Continuous Improvement (main metric from Dave Kellogg)

​Below is the presentation and here is the recording of the event. 
​
0 Comments

So You Want to be a Platform Company (Updated)

7/2/2021

1 Comment

 
Picture
​​More and more companies are trying to become platform companies. Even if you are sure what that means and why it is important; how you get there still isn’t easy.  (This update is based on a few things I have learned since writing the original blog post in 2019.) 

​
WHAT
While the term "platform" can have a broad range of meanings in just the technology market, the  focus of this article is API-centric cloud platforms or platforms as a service (PaaS). These provide software functionality that enable other developers to build complementary technologies, products, or services.

Platforms and their specific APIs can be used to integrate and extend the capabilities of distinct SaaS offerings. Often this involves a client giving permissions to another provider to use their data in the SaaS platform. For example, these integrations or extensions can be seen in B2B application marketplaces such as Salesforce App Exchange, SAP Concur App Center, or Cisco AppHub.  

​They can also be used just to provide functionality for other applications and may be white labelled and not listed in the platform provider's marketplace. There are many API-first or developer-first companies whose primary offering is API-based or platform-based such as Stripe, Plaid, or Twilio. 

The targeted developers can be internal to your company, can be part of a partner organization, can be working for a customer already using your SaaS offering, or can be a completely new client just interested in using the API’s functionality.  They can build capabilities that interface to and impact the UX (user experience), business processes or workflows, underlying data, or infrastructure (such as IaaS providers like AWS) of a platform and associated SaaS offering; or again the functionality can be used just to augment the client’s offering.
 
(As described in Wikipedia, the "platform economy" includes these “innovation” or SaaS integration platforms along with B2C transactional platforms such as Uber, Amazon, and AirBnB - not to mention the data / advertising model of companies like Facebook and Google.)

Picture
​WHY
Platforms enable companies to create more value and even new business models by digitizing their services and connecting with other similarly enabled entities. For example you can connect with other platforms and/or different channels where your customers are consuming digital services: AWS, Salesforce, Uber,  Square, Microsoft (O365), SAP, WeChat, Slack, etc. 

​These business models can include direct revenue from the customers and partners using these externalized services, for example based on the volume of API calls. This would be the case for developer-first companies like Stripe or Twilio. For customers extending your SaaS offering that they already subscribe to, it could also just be an up-charge to the cost of your core products.  For integration partners, it could or maybe should be based on the value of the specific use cases that are enabled by using your APIs and the associated data. (Here is more information on SaaS pricing models)
​
What is often overlooked or at least undervalued is the indirect revenue impact of extending the overall value of your offering, it will now be made up of both your products and services and the complementary products and services of your partners. This can lead to benefits such as a higher competitive barrier and a higher base cost of your core products. 

The biggest mistake I have seen across a variety of companies is not coming to agreement on the value they want to create with a platform.
​Is it:
  • Direct revenue (often emphasized too much too soon)?
  • Indirect revenue (expanding the offerings a customer can build or get from a platform-based ecosystem increases the possibility a customer will buy and not attrite)?
  • PR/marketing around becoming a platform company?

Platforms and platform partners ecosystem also enable viral growth by creating a network effect: the more APIs being exposed and the more data that is accessible
  • leads to more paying partners creating more applications, integrations, and value
  • which leads to more customers using (and paying for) your platform and generating more data (and you externalizing more APIs)
  • which leads to more paying partners creating more applications, integrations, and value.

Picture
Platform and APIs can also lead to happier or at least more easily retained customers (leaving you may also mean leaving or at least changing how they interact with vendors from your partner ecosystem) and a lower cost and higher win rate for big prospects.   The customization afforded in an on-premise world can be more easily replicated for SaaS when there is a platform.  Often you have to say "no, that is not on our roadmap" to a big prospect who needs some specific capability (often for big enterprise prospects it is an integration into a legacy system). However if you have a platform your answer can more likely be "yes, you can do that via our APIs, let's show you how or introduce you to a third party integrator."  (This is certainly one of the few times you'd say "wow, the cloud is finally catching up to on-prem.")

​Later technologies such as blockchain could usher in new era of api-driven business models as Joe Liebkind contends. However much like the same way that 25 years ago we couldn’t imagine the value and capabilities the web delivers today; we have little ability to understand how the proliferation of blockchain’s distributed, trusted, transactional capabilities will impact our economy (more on this in an upcoming blog post). 
 
HOW
Whether building from scratch or undertaking the long, difficult journey to transform current (often on-premise often monolith) software to being services and API based; it's going to be tough.
 
In short, you need to consider your platform business offering like any other business offering
  • What are the objectives or strategy
  • How are you going to design, build, test and deliver it
  • How will your customer use it
  • How will you manage and maintain it throughout its lifecycle
​(Themes emphasized by Carol Russell and Forrester’s Randy Heffner)
 
Another way to consider the business plan for an API or platform is the API Model Canvas (created by Manfred Bortenschlager based on the Lean Canvas).
Picture
Platform strategy can also be considered through the lens of developer experience.  In an often quoted 2012 speech by John Musser at the O’Reilly Open Source Convention, he said that the
​5 Keys to a Great API are
  • Provide a valuable service
  • Have a plan and a business model
  • Make it simple and flexible
  • It should be managed and measured
  • Provide great developer support

Every platform requires developers; here are a few tips to provide great developer support and build a vibrant developer community
  • Develop inbound SEO acquisition and brand to attract developers
  • Create scalable content (tutorials, guides, API references)
  • Build community and boost champions
  • Have a dedicated developer support and onboarding team (You need people focused on the success of the big partners that your PM and BD team recruited to expand your offering.)
  • Understand your audience (and not all of them will be developers. The decision makers and stakeholders in partner companies will include CROs, business  development executives, and CEOs!) 

​Platforms and Product Led Growth
Platforms can help you expand or build your offering and your company in a variety of ways: by organically or inorganically becoming a multi-product line company (good luck doing this without being a platform company), by enabling system integrators (SIs) and value-added resellers (VARs) to implement or extend your SaaS offering, by enabling product partners to provide integrated related functionality, and by allowing you to more easily integrate with supplier partners that provide functionality.​​
Picture
To be a successful product-led company, you need to have a view on the ecosystem in which you compete and how you use your platform to build, buy, or partners your way towards more growth and providing more value. ​ This may be the most important job of product owners and GMs. However unfortunately many of us just think about what we can build next and even worse what is the next incremental improvement to what we have already built (10% faster, 10% less bugs).
1 Comment

Don't Listen to Your Customers

6/6/2020

0 Comments

 
(or at least just listen to a select few when considering long term SaaS product strategy)

SHORT TERM SAAS PRODUCT STRATEGY
You should definitely be listening to clients, partners, internal stakeholders, prospects, and product metrics when considering what to do next with your current products - your short term product strategy.  As discussed in SaaS Product Metrics, the KPIs for these products could include win rate, customer adoption, customer NPS, short term revenue, and alignment with the your company's (short term) KPIs and metrics. 

However your short term SaaS product strategy is often focused on market penetration; it is usually a bottom's up view of how to maximize the value of your current products in your current market (your current customers and customers like them).  The Ansoff Matrix, one of the frameworks mentioned in Notes on Software Product Strategy, illustrates that there are other perspective you can consider for your SaaS product strategy.
Picture
LONG TERM SAAS PRODUCT STRATEGY
You can consider what future products you can sell into your current markets by creating a (future) product development strategy.  Also you can consider how to modify your current products to sell into future markets as part of your market development plans. (Both of these strategies are easier if you are a platform company; API-centric cloud platforms enable developers to more quickly build complementary products).  
As part of this longer term product strategy you should consider 
  • Company vision and longer term company strategy
  • Market forces (For example conside Porter's Five Forces framework which is discussed in Notes on Software Product Strategy:  competitive rivalries, power of suppliers, power of customers, threat of new entrants, threat of substitute products). 
  • Competitors in these new markets and for these new products
  • Ideas from a few of your best and most visionary customers about
    • how your core capabilities can provide value in other parts of their business (future product development)
    • how modified versions of your products can help these customers grow in other geographic / vertical markets.
In other words, you need to build your perspective on a given market and how your offerings and distinct value proposition fits into this ecosystem. 
Picture
And remember you need short term deliverables for longer term strategic goals agreed upon across your company as there will always be pressure to use that capacity to accommodate short term revenue requests.  There will always be an inherent tension between the Sales team who is paid to deliver monthly and quarterly results and the Product team who is paid to consider quarterly and yearly impact.  

And there will always be less capacity than you think. 
Picture
0 Comments
<<Previous