I led the team who built and delivered Mastercard's first A/B testing service. We launched with Click to Pay, helping drive transaction volumes in the millions and securing billions of dollars in transactions along the way. We were thinking in business experiments. That's how we should think about anything we're building: by definding what we expect up front, helping us sharpen when to stop, pivot and invest (borrowed from Survival Metrics).

Today a friend called me remarkably prepared. I loved it. She'd written a Product Requirement Document for an AI powered Talk Therapy service. Whatever your sentiment on Product Requirement Documents -- my friend has a Doctorate helping people navigate their lives better and I don't think they are spending time talking about gathering requirements, Software Development Life Cycle or working with engineering.

These are fun conversations for me.

She's a Subject Matter Expert and those people are the best positioned today to solve problems. At some point in the past I would have introduced her to developers or an engineering team that would deliver a quote for what she wanted, a month later they'd probably still be chatting.

The cost of getting started has changed.

Today utilizing Cursor + Replit paired with OpenAI's API, she could reasonably have her talk therapy service up and running this week. It feels great being able to speak and share that counsel. You can build things fast. The same tradeoffs between time, money and quality exist. Your service will have the same problems that it would if someone was speaking directly to the large langugage model. You may have the benefit of a larger context window with OpenAI, that functionality may have different limits with Google's Gemini or the other LLM providers. The guardrails you want to put in place may take more time (tradeoff: higher quality or faster to market?).

Then there's the question of should we & could we build this. Regulators, professional standards organizations -- all of these players have an opinion. Rightfully so. They are here to protect the public. Sam Altman has already stated that he thinks the optimal way forward is to put the technology out there and learn/create safety along the way. That's scary, but that's the reality we live in. Good American regulation gives us enough wiggle room to create. Responsive and thoughtful governance hopefully stays closely.

This can help you move onto the thing that matters: commercialization and Go To Market.

Soloprenuers and teams struggle with this. My sense is that we don't think about commercializing technology. We spend so much time thinking about building things, but the biggest risk is will people use it. Adoption, sales, these are really important.

Sales brings home the bacon. We need to bring home those sales then hire help when there's too much. Sales is the core function required of any team building tech. Sometimes you are selling ontop of existing deals and sometimes you are selling to someone out of the blue - hopefully you've got traction and credibility for that.

The advancement of technology helps us get things out the door more quickly. Still its:

- Ship before you're ready

- The smallest team for the job is often the best

- Start with business questions: how will you make your first $1000, who will be your first 100 customers, how do you know if its working.