What’s Cookin’ in Hook-land? (First Edition! Feedback wanted)

We’re trying something that frankly we should have been doing for 10 years. Our weekly newsletter. The basic format is simple- a small personal note from moi (Sean), the meat: Things we’re seeing; Things we’re hearing; Things we’re doing. I added everyone I thought might be interested in a quick and thought provoking read about integrations… please don’t hesitate to unsubscribe! And on the flip side, please let’s thread about whatever catches your attention. Okay cool. Let’s rock. On a personal note... Aloha! What are you supposed to do for the first missive for a newsletter? Let's go with a bit of a personal journey/origin story. About 15 years ago, after multiple group conversations, Speakeasy Dinner series (happy to explain more later... a guest was invited to join a group of us and share their personal beliefs and stories, and the only rule was the guest talked, we listened and asked questions), philosophy classes, debates, and more... I gathered that I had a gift/knack for asking questions that were on people's minds. For a long time I thought I was annoying. Always asking questions when someone said "does anyone have any questions?". Always having "one more thing" to say. Often having the impulse to have the last word. I blame growing up in a family of 5 kids, all 7 of us extroverts. Anywho, my shame shifted when I repeatedly started hearing things like "thank you for asking that question, I wasn't sure how to ask it and that was perfect" and "listening to you go back and forth with them really helped me follow along". So, I started thinking I potentially would go into public speaking, or politics, (or becoming an outdoor education PhD student) Enter: seanspeaks You may (or may not) have noticed my handle in about everything I could claim. Sean Speaks. Sean's Peaks. Fun little wordplay. To wit: I grabbed sean-speaks.com about 10-15 years ago. Now I have seanspeaks.me I snagged seanspeaks@gmail.com after graduating GitHub, LinkedIn, Instagram, Savvycal, Dev.to... all seanspeaks So, here I was, pretty convinced I had a gift to share. A bunch of handles and domains primed and prepped. Annnnd I never did anything with it. I'm happy to unpack why, I've got a few theories/explanations. But I'm here to change that. So what’s changed? Basically, I’m getting over my impostor syndrome. I thought for sure I didn't have much to share as I got deep into a niche area of expertise. I've been working daily with people who are experts in their respective fields, who know more than me and who have responsibilities that far eclipse mine. Turns out that I've been building my own little area of expertise now going on 10 years. And I haven't shared any of it publicly! Instead of sharing and building together, we've just been letting everyone figure out their own way, no notes. We eat sleep and dream APIs and product integrations. I’m like, 85% positive you do not. For example, I'm not sure how many people are working on a diagram like this: As they try to answer the question from their brother in law "are you automating anything in your personal life right now?" Consider this newsletter as an attempt to course correct. I would love to hear more from you as we do this, and possibly do some guest interviews where we talk through strategy questions and insights. I know this newsletter will have a diverse audience with different backgrounds, job responsibilities, company and product types… but I think we can find the through line at the API and integration layer. So take a look at what we’ve got, give me feedback please, and feel free to unsubscribe at any point or forward this along to other people you think might find it valuable. Thanks! See you next week! Best, ~Sean What we’re seeing It's going to be hard to write this newsletter without repeatedly discussing MCP, AI in integrations, and the impact of all of it on product development and company building. We'll try to mix it up a bit. But... I gotta start with MCP. Model Context Protocol. (If you're deep into the MCP weeds already with me, just scroll to the last paragraph of this section where I make my "so what" case) Let me summarize for those who don't know what it is- it's a protocol (a set of APIs you build, with certain responses) that has two parts... the server and the client. The server's job is to expose a pre-determined set of APIs, and the responses must be formatted in a certain way in order so that a client LLM can understand and use the tools it exposes. To make it even simpler- ChatGPT and Claude (et al) can use external tools, but they have a hard time understanding pure API documentation etc. Instead of trying to just shove a spec at an LLM ("Here, read this, good luck!"), we can give it context in a format it understands, and then give it some code it can run to take advantage of a tool. So now we say "Hey, here's a set of tools, like 'Search HubSpot Deals', that you can use if you think the user is looking for it. And if you determine you want to use the tool, here are the actual values you need to provide in order to properly use the tool." And by "we say", I mean that whoever built the MCP Server makes it say that in a predesigned formatted response. And the MCP Client (Claude Desktop, ChatGPT, Cursor, etc.) know how to use that server and response to feed their LLMs. Here's a little diagram: credit if you want to go deeper Okay, so what. And what does this mean for me as a product owner, a product user, or someone who's just trying to get a thing done. My bet is you've used ChatGPT or Claude in the past month. Or you use AI regularly. If you've installed an "integration" onto Claude, you've likely already installed an MCP server reference. Ditto ChatGPT for any of the deep research connectors. The way we see it... 10% of the population will ever care or need to care about what an MCP is. The same way they need to ever care what an API is. MCP is an enabling technology for a new sub-type of integration. So, what does that mean for you, the product owner? Or you, the engineer? Or you the partnerships person? It means that you should come to the party not only with your API well built and documented, but also your MCP server. I'd bet my house that in 3 years, the developer experience of most of the major app marketplaces will include places for you to define tools you want an AI to be able to use, or to "BYOMCP"... plug in your MCP server and whitelist the tools you want to make available as part of your integration to that platform. In the future, your "HubSpot app", once installed, will give HubSpot's Breeze AI superpowers on top of the rest of the integration workflows and code. Be ready, explore it for your own AI assistant, and let's talk about more if you'd like :-) What we’re hearing The past few weeks we have been having a lot of conversations about when and if you should be building integrations. Specifically in the case of "as a software product owner, when/if should I build integrations for my end users?" You would think the answer is “now” and “of course, all of them”. Especially from someone who makes money off of them existing. And yet! There are absolutely times when you shouldn’t be building a bunch of integrations. Let’s lay out a few: Freshly building an app? If you don't have target customers in mind, don't build integrations yet. Find and talk to them. Smoke and mirrors a few integrations if they're core to your idea. But only so that you can get a response from folks to understand if it holds any water. Super niche category? Some categories just don't have a lot of potential integrations to build. And they wouldn't make sense to build except for on the edge cases or a few core clients. In these cases, I usually lean towards "go with professional services" or "build a connector on and point people to an iPaaS". Have a lot of lightweight integrations already? If you've already got a few dozen integrations that do a few things well, it's probably time to loop back and make them better. Improve on them. Ask for wishlists from your users. Figure out what capabilities the platform has. See if you can get some co-marketing going if you enabled a certain pet feature that the platform cares about. Don't know where to start? Do you have a strategy? Some folks have a good product sense and are building products that they themselves wish existed during a previous job experience. In that case, run with what you think should be integrated. But in the case where you're not certain of where you're trying to swim next? Pause. Research, ask customers, get a list, and check on your strategy. Way too many horror stories out there of apps/integrations that were built hoping to find a user, only to be left unused in the back cupboard. We've built a few ourselves On the flip side, I think a lot of product owners and devs are slow to catch up to how much AI has changed the game on developing integrations for their products. Or, if they've caught up, they're also not fully aware of the pain they may be vibe-coding themselves into going forward. I've got thoughts on both counts. Ask me anything :-) What we're doing This part is fun. If you haven't been following along on my LinkedIn posts, then a quick recap- We've been playing around with MCP implementations... putting them in front of a Frigg instance, working through a concept I like to call "LLM-detected workflow hardening"... okay I just made that up, but the point stands. What if you had a plugin you could add to your favorite chat tool (ChatGPT, Claude, etc), that let you talk to your external tools. Then, as you kept doing your thing, prompting away... it came back with: "Automatable workflow detected! We noticed you've been making a lot of these similar requests in a row with similar prompts. To increase accuracy, reduce cost, and improve speed, we can make this into code and put it into a new tool for you to use. Do you want to do that now?" and it would generate the code for you. Then, if you wanted to, you could push to the cloud and let anyone on your team or company leverage the tool themselves via their own preferred chat agent. That's a fun project. We put together our own RAG AI Agent based on just our conversations and docs... Lia (Left Hook Integration Assistant) is our spike (2-3 day engineering binge) on the idea that, if you give an LLM enough domain-specific context, then let it retrieve from that data (via "RAG")... you can get stretch your hard-won expertise a whole lot further. I was dubious at first, but after trying it out, it was compelling enough for me to make a pivot on how we want to build out a new website. Lia is going to take center stage. Message me if you want to try it out! We've been trying our hand at using different embeddable iPaaS's for clients and for our own evaluation... We've been asked by a few clients and folks to give us a quick rundown on their embeddable iPaaS options. I've got a whole conceptual framework we can run you through to help you evaluate, but I also wanted to test out the developer experience in each one. Paragon, integration.app, Zapier, Make, Ampersand, Tray, Workato, Cyclr, AppMixer, n8n, and more... we've been playing around with and have some thoughts. AMA Spikes, Sprints, and rapidly increased development speed with AI... Probably a good note to end this first newsletter on: we made some tweaks to Frigg recently, and have been relentlessly fine-tuning our use of AI tooling, that have me hopeful we'll see a 200%-400% improvement to our development speed from just one year ago. That's on top of the 2-4x speed improvement we've seen since Gen AI slammed onto the scene. With that, it's kind've borked our business model. The fixed fees that we sold 3 years ago no longer make sense. But also the space is so new, and a bit unpredictable (Happy to go deep into the weeds of LLM being probability machines that reduce predictable output), that just billing for time and materials ALSO doesn't make sense. So, we're trying something new. Selling spikes (a few days) and sprints (a week at a time), and being up front about our costs. Spikes are centered around my core belief that we really don't have a good grasp on what we should build together until we all get our hands dirty in the code. 10/10 times, once code is down and you can see your integration live, you make more accurate and complete scoping decisions. So, we're doing PoC spikes. I legitimately will not be surprised if our spikes yield ready-to-launch integrations for a number of folks. But the bare minimum is to get to a scope we can all agree will hit the metrics we want, and be good to launch. Sprints come after, once we know the scope to build. We just run hard at getting you the best built integration, with GTM ready-to-go, over the course of however many weeks you need. We'll either yield back unused time in the form of credit for future work, or we'll run at your wishlist. Either way, what I'm optimizing for is speed and time in market. I'm sick and tired of needing to wait to build things we know would be valuable and increase the outcomes for you and your customers TODAY if only we could just run at it. We're in the lab daily. Hit us up with questions. Let's talk! Thanks for reading the first edition of our inaugural newsletter! Reply to let me know your thoughts. What do you want to know more of? Smash that unsubscribe button below if you don't like it. Forward to a friend if you do! Until next time! ~ Sean Matthews Co-Founder Left Hook