TetraMesa

The Interface Taxonomy Beyond APIs (2 of 5)

By

In this part 2 of 5 for the series, we’re going to look at the “What & When”

The fastest way to make this whole topic area a confusing mess is to just list out technology definitions, though at some point we need to visit REST, GraphQL, gRPC, webhooks, Kafka, WebSockets, MCP and A2A. They don’t all sit at the same conceptual level, and they’re not interchangeable answers to one problem. What we’re going to do is look at some use cases. And later on some actual examples and things you can try yourself if you want to dive in a bit. Again, not trying to be coders. We won’t be experts. But sometimes just seeing something actually work can be those Aha moments we can keep with us over time vs. just spewing buzzwords. We’ll get there.

In the meantime, a useful product taxonomy can perhaps start by asking ”What interaction are you trying to create?” Then look at technologies that can do it. Or ask your dev or architect counterparts.

Things like OpenAPI and AsyncAPI can describe interfaces. OAuth 2.0 handles delegated authorization. JSON and Protocol Buffers represent data. SDKs package interfaces for developers. HTTP, WebSockets and MQTT move information. Those things matter, but they are not all separate product interaction categories.

[Read more…]

Product Leader Mental Models of Connectivity Beyond APIs (1 of 5)

By

In this part 1 of 5 for the series, we’re going to look at the “Why”

Why APIs and Interfaces need a fresh high-level consideration.

We know the role “Digital Product Manager” has always been ambiguous, at best. PM, Tech PM, Marketing PM, now AI PM, etc. Ideally, anything with “Product Manager” in it has something to do with market awareness, looking around corners, at higher levels and so on. A lot of us may have come from some kind of coding background, but certainly not always. In any case, even if we don’t, (or shouldn’t), need to be expert developers, at every level we should understand how our products are stitched together.

[Read more…]

Poor PMs Guide to AI Image Generation Workflow With n8n

By

A practical setup for kicking out a lot of decent hero images fast, plus the decisions that mattered more than the tools.

Note: Files for this project are available here: GitHub: n8n-blog-image-pipeline

Here’s one from the “Practical Product Quick Build Toolkit.”

I needed bunch of graphics for content. Here’s how I got solid results quickly and inexpensively.

My focus is on product, not production. But time and money were factors (as always) so this was the fastest way to get things done while leaving a reusable workflow for future needs. There’s a variety of tools for this sort of thing, but I wanted specific direction with general rules. Not just “generate an image,” but a repeatable system that produced a consistent series.

Using a workflow agent tool like n8n coupled with an image-generation model did the trick. I could set images to get generated and then do something else. A few caveats up front: you still have to check the images. Every one. And you won’t own the copyright as you might with commissioned work. But you can kick out what you need fast. Even if you’re only using them as placeholders for a prototype or something, you can replace with better stock or custom work later. For a prototype test that just needs a quick hero image on every page, that trade is worth it. And this will work for a production site as well. But for highest level of quality, professional stock and commissioned work can replace these placeholders. If you’re using a full site AI generator, those will usually be able to make your graphics. But if building with a coding assistant, perhaps not. Here’s a solution for that. Create the graphics in bulk, stage them somewhere with know filenames, (ideally based on direction directly from a coding tool), then load them into your site’s image folder.

Here’s the setup, what it cost, and the rules I’d carry to any similar project. The tooling is the least interesting part. The decisions about what to automate, what to keep human, and where quality actually comes from are the ones worth consideration, whether you’re building this pipeline for one time bulk use or deciding how this AI tool flow fits into your product.

[Read more…]

AI Build Copilot, Part 6: MORE Bonus Bits & Pieces

By

It doesn’t matter what you’re doing. Product Management work, Creative work. Requirements. Code. We’re all over these tools now and across disciplines, we face some of the same challenges. Here’s yet another set of practical snippets for dealing with AI-assisted coding and building. The tools can move fast and sometimes faster than we can track. This installment collects a few more practical habits for staying in control. These are the small, deliberate practices that keep “trust but verify” from turning into “hope it worked.”

[Read more…]

AI Build Copilot, Part 5: Bonus Bits & Pieces

By

Intro

I thought Part 4: Preparing for Production was going to wrap up the series. But wait, there’s more! Not every useful lesson about building with AI tools fits neatly into the larger themes of the past articles in this series. So this final section is a collection of extra bits and pieces that don’t quite belong anywhere else, but may still save you a lot of trouble. Yes, I could have just called it “Misc.” I suppose. But in any case, there’s just some random bits that didn’t fit cleanly into earlier docs and fell out of the edits.

Here they are in one random walk place.

[Read more…]

AI Build Copilot, Part 4: Preparing for Production

By

Part 3 was about building durably, so what happens after that? A successful prototype creates a new problem if you actually put it into some form of production. Not too long ago, if we built what we called prototypes, maybe they went to user testing, or we ‘sort of’ put them out there. But now? A lot of so-called tests really aren’t. That is, they’re really more actual rollouts. Just maybe not necessarily with the same rigor we used to give product launches. The line between that which was intended as prototype testing and so-called Minimum Viable Product (MVP) seems like it might get blurry.

The next challenge with launching a kind of prototype, but that which is maybe real product is someone may decide to use it. So… Is it really a prototype? Meaning… is this just some brochureware for testing or is there actual sign-up functionality, any kind of real billing, private information collection, and so on.

This is when the low-stakes experiment begins accumulating customers, private information, billing relationships, operational dependencies, and consequences. You have to make your own call on this kind of thing. I have to tell you, personally I’ve never loved the “false front door” thing for testing. I get that it can be useful, but sometimes it’s on the edge of unethical in how it seems to trick people. If your prototype is really a test and that’s understood, great. If the truth is it’s not much of a test, but a rollout? Then there’s probably some more risk elements and due diligence that should be covered.

Prototypes have a way of becoming products. Temporary credentials become permanent. Test data becomes customer data. A one-time API connection becomes a critical service. The final part of an AI-assisted build is not clicking Deploy.

It’s deciding whether the thing can be operated safely. One thing that I’ve done along the way when building is created something I’ve called “Launch Blockers.” This is different than a UI backlog or minor changes you find along the way. It’s things like purging schemas, or making sure live production feature flags are set properly. It means a real security review. Things like that.

[Read more…]

I Built a Joke Site with AI – Then It Became a Production System

By

This started as a joke that got out of control, but the build produced a few lessons worth sharing.

Most of my work is product-focused rather than production-focused. Product and marketing people should spend their time with customers, markets, competitors, business models, and worthwhile problems. Becoming absorbed in production can turn attention inward instead of outward.

Still, sometimes you need or just want to build something yourself. Like everyone else, I now use AI for all manner of things. But there’s a difference between a throwaway prototype for quick user testing and something that might approach production. For one project, I had to move beyond simple prototypes and build a modern AI-assisted production pipeline without experimenting on a client’s product, a company’s core offering, or anything containing important customer data. So I needed something harmless, but sort of real, to test with. To borrow from my woodworking hobby, I practice new techniques on cheap material before touching fine red oak. The same principle applies here: make early mistakes where failure costs essentially nothing.

So I built a joke website, but the tools and methods behind it are no joke. They are genuinely powerful. At the same time, the more serious project benefits from using this as a no risk practice platform. So here’s where we come out:

  • This article: I’ll just tell you what I built and some of the tools I used to do it.
  • Next Up: A series on AI Build Copiloting in general for “semi” technical users. That is, product folks with some basic engineering familiarity, who need to dive a bit deeper into these areas, even if only part of the time.
  • After that: Another series focused on building in databases with AI assistance.
[Read more…]

Part 1: Stablecoin Flavors – What Are You Holding?

By

Stablecoins are moving what we call Crypto more towards just “this is just Digital Money now.”

This two-part article series examines the current landscape of various “stablecoins” to clarify labels that often sound functionally descriptive but frequently aren’t. It also highlights under-discussed aspects in this evolving space. We need clearer understanding of what these assets are and as importantly, what they’re not. Even with the GENIUS Act and ongoing work on the CLARITY Act, significant ambiguity remains for some token types.

Stablecoins are not one thing. They’re a family of tokens with dollar-like claims, and the important questions aren’t whether they appear stable, but what kind of claim they represent, what backs them, who gets the yield, how they redeem, and what happens under stress.

Along the way, I’ll go into some of the oddities and implications of stablecoins. Some may seem slightly off topic. However, they’re all part of what’s becoming this ecosystem and therefore I believe useful in understanding how things fit together.

[Read more…]

Of Oracles & RWA Headwinds

By

Tokenization of Real World Assets (RWA) is on a tear, but will some aspects be held back from mass market adoption for lack of trusted information about certain types of assets? Today’s Oracles, (that supply external, off-chain information to a blockchain or smart contracts), don’t seem ready for richer types of information that we’ll need. Today’s oracle infrastructure is better suited to selected structured data points than to richer, messy reporting packages such as engineering reports, appraisals, legal exceptions, maintenance issues, lease details, or materiality judgments.

Mckinsey estimates tokenization markets worth somewhere from $2T – $4T by 2030. They aptly point out, “Tokenization’s rate and timing of adoption will vary across asset classes” and “Given their characteristics, certain asset classes will likely be faster to reach meaningful adoption.” In other words, easier things will happen faster. Obvious enough. Others assessing future tokenization markets show more of the usual charts with curves bending quickly upwards. The more challenging areas though, will be where they’ve always been challenging in terms of regulatory issues, information flows and so on. When we get into “REAL” real world assets is where things are harder. That is, things like gold, mutual funds, or others that are already virtualized really, should translate more easily to representative onchain tokens than messier deals such as a local shopping center development, a piece of art, or similar. Let’s say a token says you own part of a building. But what if that asset has a problem? Who reports it? Where does the report live? Who’s liable if nobody updates investors?

Traditional finance has longstanding reporting structures. And they still get things wrong sometimes or suffer from fraudulent claims. When we build an abstraction layer like a blockchain on top, we need ways to bridge a reporting gap. Successful adoption here isn’t going to be about just splitting things into smaller pieces with tokens. It’s time to look at why and suggest some solutions.

The idea for this post came out of a LinkedIn thread where Igor Samotesov talked about why trillions aren’t flowing quickly into onchain RWA instruments. And I just happen to be re-reading a book on taxonomies. So this is the result. Here are some more potential reasons for what’s going on and possible solutions.

[Read more…]

Using Skills for AI Builds: Product Safety

By

Note: This isn’t about general skill in building things with AI… it’s specifically about things called Skill files or their similar counterparts.

Are you a product person at any level who is either building yourself or managing others that are increasingly doing some direct building?

Like a lot of us, I’ve been making some of my own stuff with AI tools. Or in some cases experimenting to understand their use cases better. Among the hype cycle things of this year are Skill files. (Or more generally skill type instructions for AI tools.) There’s whole marketplaces for them. This post is just a warning I’m throwing out there as a caution along with some ideas for mitigating risk. It’s not meant to be overly alarmist, but the “You can use skills to do anything!” hype is so overwhelmingly thick sometimes, it just needs some balance. And actually, I think it’s not just clickbait, it sometimes feels irresponsible and dangerous.

[Read more…]

Location

We're located in Stamford, CT, "The City that Works." Most of our in person engagement Clients are located in the metro NYC area in either New York City, Westchester or Fairfield Counties, as well as Los Angeles and San Francisco. We do off site work for a variety of Clients as well.

Have a Project?

If you have a project you would like to discuss, just get in touch via our Contact Form.

Connect

As a small consultancy, we spend more time with our Clients' social media than our own. If you would like to keep up with us the rare times we have something important enough to say via social media, feel free to follow our accounts.