Just five or so years ago, if we wanted to put a real product in front of a real customer and be in a position to ask them for real money, we’d have to spend a few hours coding (and potentially learning to code) or hire a couple of programmers to build something out. We’d also have to host this app and do all of the wiring to get it live. Oh and we’d be basing this on a product strategy built on a couple google sessions and gut feeling.

Now? We can research fast. And design fast. And built fast. And launch fast.

This past Tuesday, I was privileged to host a session at Bentley University on this topic. To market the event, I promised we’d take a student idea and build a product strategy around it. Then, we’d build a working prototype we could put in front of interested customers. That was a big promise that, in full disclosure, I wasn’t 100% confident I would fulfill. But, lo and behold, it worked! We built a decent prototype that would - with some backend changes - fulfill the problem we set out to solve. Here’s how we did it and the tools we used. Of course, you should receive this plan as merely my thinking and let it inspire your approach.

Tools:

• LLM. I used Claude as a strategic thought partner. I like Claude although at times it can be too verbose and often lean hard into my ideas rather than tell me an idea is a bad one. I use chatGPT a lot too, and find it to be helpful. Either would likely work for this exercise.

• “Vibe-coding”. I used Loveable to build the prototype. I think it does a good job interpreting ambiguous product requests and properly building modern app experiences. I use it for other projects and while credits can add up fast, it’s possible to use it. For $60, you could use it for two months with more credits and then downgrade to make minor changes in incremental fashion.

Pre-Requisites:

I follow the following steps to shape the idea.

Important pre-requisite: Each step depends on pre-loaded (or attached) instructions that are at the bottom of this article. Load the instructions first.

Keep in mind a few things:

1. I favor simplicity. The frameworks, definitions, estimates, outcomes are all purposely simple.

2. You will likely need/want to re-prompt, go deeper into a topic or ask Claude to adjust based on a business goal. For instance, in the example we did in our session, our idea failed to reach profitability. Realistically, I wouldn’t have built a prototype before figuring out a sound business plan. This would require a few repetitions with your LLM.

3. If you get stuck and can’t get clarity around a good business/product strategy, consider that a good thing. Maybe you need to rethink your idea, your model, your market or something else. Better to learn this now, then after you’ve built a prototype.

4. At every step, when you make selections about the business (the strategy, the customer, the positioning statement), you must tell your LLM so it knows moving forward.

5. Have fun with this and make sure you adjust your instructions to your liking.

Building a Strategy with an LLM:

1. Open your LLM of choice and load the instructions at the end of this document (edited to your liking, of course).

2. Write out your business idea in plain text. This is the basis for all the remaining steps as we transform this idea into a working project. Use as much detail as you’d like and try to identify the problems you’re solving, how your solution might work and who would stand to benefit from your idea.

3. Construct your problem statement. Turn your business idea into a problem statement. Paste your business idea into the LLM and ask the LLM to create a problem statement based on it.

4. Perform an opportunity analysis. With your problem statement in hand, ask the LLM to list the opportunities. It’s possible you’ve only got one. But likely, there’s a few things you could do with the idea and it’s important to list those out so we have somewhere to start. The instructions (which you’ve pre-loaded) include a weighted scorecard that will priority rank the opportunities you can pursue. Tell the LLM which opportunity you’d like to pursue with your business.

5. Build a competitive analysis. Now we need to know who solves that problem today. Not just potential competitors but other substitute solutions (public transit as a “competitor” to ride-sharing for example. We also want to know if the customer solves this on their own. The competitive analysis will draw this out and - most important - start to help you figure out why you’re different.

6. Pick a strategy. Now that we know the competitive space, we can figure out our corporate strategy. Will we just be less expensive? Unique in a new way? Focused on the broad population? Or just a sliver of the market? Prompt the LLM to help you devise this piece.

7. Choose a differentiator. This step is closely coupled with the one before it. If we’re differentiated, then how? With our competitive analysis we can begin to lay out opportunities to differentiate. Note: if none exist, maybe we circle back to step 4 and pick a different opportunity.

8. Define your customer. Of course, we need to sell/cater to someone. Let’s figure out who our customer is. Build out an ICP (Ideal Customer Profile) with the LLM. An ICP is a definition of your customer that is likely purchasing your product. You could have a primary user persona too, and sometimes it’s the same person. With the market, problem, opportunity and differentiator defined, it might be rather easy for the LLM to pick out the person who’d be interested in your company. In the marketing world, an ICP can be a lengthy, detailed description of the customer. As promised, our instructions keep this relatively simple.

9. Build a positioning statement. A positioning statement is your reason for being. It should tell the market - and prospective customers - why you exist and why they should choose you. A lot of marketing material will dangle from this asset so make sure you like it. Once again, ask the LLM to build you a few positioning statements and choose one you like.

10. Figure out financial feasibility. Now it’s important to know if your company can make money. Ask your LLM to run a feasibility study. It will report back estimated income, expenses and - of course - profit. And it will do this over the next few years. If you’d prefer to have positive income sooner, work with your LLM to drive costs down and revenue up. This step, more so than the others, may take a few rounds of prompting. When you have a feasibility study that is a) realistic and b) matches your financial goals, it’s safe to move on.

11. Plan your product roadmap. Your product roadmap is a high level plan of when you’ll build features/capabilities/additional products over time. This roadmap should correlate nicely with your feasibility plan, especially if you plan on price increases, new product offering or expanding into new markets. The product you start with won’t magically scale with these changes.

12. Focus on an MVP. An “MVP” stands for your “minimal viable product”. Essentially, it’s a definition of the smallest version of your product that would still be valuable to a paying customer. Building an MVP requires discipline and focus to ensure that your product only includes enough code to satisfy the customer problem you defined at the start. This is an important artifact as it is what you will feed to your vibe coding tool to build out the prototype. Once again, you may want to redefine your MVP as you get feedback from prospective customers.

13. Craft a marketing pitch. When we’re ready to launch, we’ll want to sweeten the deal for people coming to the site. There are a lot of assets we can build out to talk about our product effectively. But one compelling piece is an ROI stat. If possible, ask the LLM if it can calculate the potential ROI a customer would enjoy if s/he purchased your tool. You’ll want to word this carefully if the data isn’t verified. However the financial upside of your solution should far transcend the cost of the software you’re building. It’s important to educate your audience as to what that is.

Create naming and marketing assets with an LLM:

1. Build a brand. Of course we need to name this thing of ours. Use a tool like chatGPT to brainstorm some names. Or - search for available domains to land a good name. Ideally your name will be easy to remember, spell out and memorable for your customers. It’s also helpful if your name describes the solution you provide. You may also want to create a quick logo to dress up the site and for social media. ChatGPT can do this quite easily. Take some of the assets from the previous steps, mixed with your name and do a few rounds to get a logo that works. Lastly, secure a domain for your site. If you can’t get your exact name, find one with the word “try” before your name or look for a domain extension outside of the popular .com’s. For the first year, a domain shouldn’t cost too much, maybe $10 if it’s an available domain.

Build a working app with vibe-coding tools:

Finally, we have enough to build the first iteration of our app. While building business strategy is fun (for me, anyway), building working apps in a few minutes is equally exciting! Identify a vibe-coding app. As noted earlier, I prefer Loveable at the moment. Some will cost money to use fully, but look for something that fits your budget.

1. Start a new project. You have an option right off the bat: Do you want to create a working app or a marketing page to tease your product? You could combine your working product with the marketing home page into one app experience if your app is small enough. Including a “try the product” button allows the user to go from the marketing page to the app. Alternatively, you could start two projects, one for a marketing page and one for the app. This may get complicated for a prototype so I’d lean toward a combined offering or just building the application for the purpose of validating it with customers. Name the project whatever you like. With Loveable, they’ll start with some initial prompts.

2. Start prompting. Here’s where we want to describe the problem you solve, the ICP and your MVP definition. Ask your vibe-coding tool to build a solution using your problem statement, MVP definition and ICP. Hit go and let the vibe coding begin. Your tool will likely take a few minutes to build the initial experience but rest assured that your vision is starting to come together without having written one line of code.

3. Iterate. Once you get back a working app to play with, work through the app. Does it function the way you had hoped? Is anything missing? Are there small bugs or nuances? Get comfortable working with your vibe coding platform and providing prompts to modify your app. Be wary of credits however as these can run out fast. Try and keep focus on optimizing the MVP experience and building a tool that can satisfy the ROI promise built out in a previous step.

4. Consider other features. Depending on how/if you’re monetizing your product, you may want to introduce other features. For example:

   1. If you wish to have users log in on their own to use the product (as opposed to you demoing it to them), Loveable can easily implement basic (but secure) authentication.

   2. If you want to test “willingness to pay” and ask customers to pay for your service, you can easily integrate a Stripe account and payment process into your experience.

   3. Maybe you want to measure how users are using your product? Telemetry is important to understand usage/adoption/attrition. I haven’t done this one myself but it’s on my list to get to soon.

You should be good to go now with a working product. Best of luck and have fun evolving your idea into a profound business. One last reminder: As of today, vibe coding tools will only get you so far. As you scale and seek other services, you may need to build something more robust. Hopefully the steps above can help you get started, validate your idea and move you to the next stage of the journey. Good luck and enjoy!

Instructions to load into your LLM:

If using Claude, create a project and copy the text below into the Instructions section for a project. If using chatGPT, create a project and upload the instructions below as a file named “Instructions”.

Problem Statement

Build a problem statement using the following format: “[Who] struggles with [what] in [when], leading to [result], because [why].”

Opportunity Analysis

Score each problem using these weights:

• Current demand to solve the issue: 40%

• Cost to implement solution and enter market: 30%

• Competitive intensity: 30%

Competitive Analysis

Map each competitor and substitute with:

• Core strategy (using Michael Porter’s generic strategies framework)

• Value proposition

• Strengths and weaknesses

Include competitors, substitutes, and DIY methods.

Corporate Strategy

Use Michael Porter’s competitive strategy framework (competitive advantage and competitive scope) to select one quadrant:

• Narrow or Broad scope

• Cost leadership or Differentiation

Differentiator Selection

Choose from: price, features (specify which), quality (specify: reliable, fast, secure, accurate, etc.), experience, service, brand, innovation, values, community.

Ideal Customer Profile (ICP)

Define:

• Job title

• Job description

• Core problems

• Success metrics

• Constraints

Positioning Statement

Use the following format: “For [ICP] who struggle with [Problem Statement], [Product] is a [Category] that [Outcome]. Unlike [Competitor], we [Key Differentiator].”

Feasibility Analysis

Create a table showing across five years:

• Overall costs (operational, product development, COGS, marketing/sales, support)

• Overall projected revenue

• Number of customers

• Overall profit

Include detailed breakout of each item below the table.

Product Roadmap

Create a table with:

• Capability themes (rows)

• Time horizons: Now, Next, Later (columns)

Market Analysis

Define and calculate:

• TAM (Total Addressable Market): Total demand if capturing 100% of all possible customers

• SAM (Serviceable Available Market): Portion realistically servable given product, business model, and geography

• SOM (Serviceable Obtainable Market): Portion realistically capturable in near to mid term, considering competition and execution

• STM (Serviceable Testable Market): Hyper-targeted market for solution validation

MVP Specifications

Write specs for the smallest version that:

• Provides value

• Meets value expectations of ICP

• Aligns with starting price point from feasibility analysis

Include only necessary functionality as identified in the opportunity analysis phase.

ROI Analysis

Create a simple ROI calculation that:

• Aligns with ICP’s success metrics

• Uses returns generated from MVP solution

• Can be advertised to prospective ICPs

Calculate using: (Return - Investment) / Investment

Yet, this characterization isn’t fair. Conversely, the strategic PM wakes up each day wondering how the organization can deliver something truly unique. I suspect this type of PM will flourish. In fact, their star will shine brighter than ever before.

Both the successful PM as well as the unsuccessful PM will use AI, because they’d be crazy not to. But they’ll use it much differently and the good PM will learn to mix differentiation strategy with the automation capability that LLM’s afford us. Let’s think through an example…

What if we had a market with ten core competitors. The market is tight and it can often feel like a race for more features, better service or lower prices. If one competitor races ahead with a new feature, and then the market validates the efficacy of that feature, the other nine competitors can write a requirement for that feature in seconds using AI and public information. Heck, the feature can likely be developed quickly with parallelized programming agents building to the requirements. Parity has never been more achievable.

Enter the strategic Product Manager. For years, the PM was advised to not enter a feature race and take on the additional cost of supporting features and the loss of focus. Some listened, most didn’t as pressure from Sales would often lead to a neverending quest for feature parity. Now? The Strategic PM has a new, loftier goal: Identify a unique advantage that cannot be easily replicated. Partnerships, patents, proprietary code, people. These become the assets that the competition can’t mimic with a couple clicks in Claude.

Positioning based on application features is dead. Positioning based on things that Claude simply can’t write a recipe for is the new path to greatness. Easier said than done of course. But they do exist. GitHub, Wordpress and RedHat have leaned hard into a community-first strategy. Apple and Salesforce? Much of their success has been realized through their platform strategy, an endeavor that requires much more than a couple of features.

The Product Manager will now fill a void of crafting or reinforcing a company’s differentiation strategy. Companies without a differentiation strategy will suffer a different fate as they fall into parity price wars with similar companies.

Differentiation has always been the most critical component of strategy. However, AI will create a divide between the companies with a defensible, marketable, indistinguishable strategy and those without.

“I need more resources to cover the scope!”

“Nope, no additional resources.”

“Okay then we need to change the scope of that thing.”

“I don’t think we can afford to do anything less. Sorry.”

“Well then, we need more time…”

“We’re not giving you more time.”

If this sounds unrealistic, think again. Management teams do this to teams all the time. It happened to Michelangelo when he painted the Sistine Chapel. He was beaten when he took more time than allotted. (Of course he also created a masterpiece.)

Elon Musk famously forces his team into shuttle launch deadlines that defy physics. His team often do get to the launch date. Then again, plenty of his launches fail.

So how does a team make a locked in deadline with locked in resources set out to build a concretely defined product? They pull the fourth lever. When time, scope and resources aren’t variable, quality becomes the lever. So, the way to build something on an unrealistic timeline, is to simply build a crappier version of that thing. I wrote “The Quality Lever” two years ago. The basis of the book was to define quality up front, before considering time, resources and scope and to build this thinking into the fabric of the organization. I still believe in this principle and I see companies screw this up all the time. It’s a culture problem.

Here’s the catch: Sometimes (but surely not all the time) a lower quality product is perfectly suitable. It might even be preferred. For instance, if a team is validating market demand or a design or simply want a jumping off point for feedback, then a low quality experience is a good way to ship something, learn and optimize later. Some would argue this is the basis of product management.

When management teams ask for that thing by that date by that resource, they should have a good read on risk tolerance. Assuming low quality, will it tarnish our brand? Will we put this in front of a safe audience who can imagine a better future? The real wins come from delivering product earlier that serves as a learning point. The real losses come from building something quick and dirty that should have been better.

I teach a college course on innovation, and as you might expect, we spend a lot of time discussing AI and the transformational era it has ushered in. For the first time, we have the data, computing power, thought leadership, and commercial tooling to truly harness AI as a utility. I often tell my students they’re fortunate: yes, AI will replace some jobs—but it will also create new ones and unlock massive opportunities. Early in my career, I spent countless hours as a business analyst compiling reports for internal teams. Today, an AI agent could likely handle that in minutes.

The same shift is underway in software engineering. Routine, repetitive coding is increasingly being handled by AI, allowing developers to release more code and features at faster speeds. What may be a strategic advantage today will become table stakes in just a few years.

But here’s the real question: are we truly ready?

Yes, I know—I named this blog Build It, Ship It. So how can I possibly argue against shipping more product, faster? I’m not. And I shouldn’t. But many books have been written on the dangers of bloated feature sets and building beyond what’s necessary. For the sake of this post, let’s assume every feature shipped provides real, validated customer value. (Imagine a world where AI agents actually improve existing features rather than just adding new ones. That’s a future I’d like to see.)

Still, in a world where AI accelerates product delivery, what does this mean for the customer?

Let’s consider a simplified version of the software value chain. Today, the bottleneck exists within R&D—features and requests pile up in the backlog, far exceeding what teams can deliver.

If AI speeds up the development side of the equation, does that backlog suddenly disappear?

Not quite.

As “Development” accelerates, we need to examine the rest of the chain. Can your Design team keep up? Can AI effectively test and validate design hypotheses, run customer feedback loops, and maintain a consistent UX across platforms? Perhaps, but it’s not getting nearly enough attention.

And what about Architecture? Can AI consider long-term system health, scalability, and risk in the same way a seasoned architect does? Even if you solve the development bottleneck, architectural decision-making could become the next constraint.

Let’s say we overcome these as well. QA has been using automation for years and is well-positioned to adopt AI-driven testing. While writing test plans and handling edge cases may still need human oversight, this function seems adaptable. But now we hit a different kind of bottleneck.

My favorite definition of product management involves balancing value creation with value capture: we can’t monetize what we don’t build, and we shouldn’t build what we can’t monetize. So, the question becomes: can your go-to-market teams keep pace with accelerated product releases? The logjam has moved.

Will Marketing be ready to effectively launch new features? Can they update messaging and positioning quickly enough? Will Sales be enabled to speak confidently about new capabilities? Can Support teams learn fast enough to guide customers through the latest updates?

Most software leaders might shrug and say, “Bring it on.” Faster development is a good problem to have—one they think can be solved with more resources or, again, AI agents. I don’t disagree. These bottlenecks can be addressed. But I’m not convinced most leaders are even anticipating this issue. They’re focused on speeding up R&D because roadmap delays are the most visible pain point—and their competitors are doing the same.

The real call to action? Strengthen and scale the rest of the value chain. Make sure your organization can absorb, communicate, and support a faster stream of product delivery. If you don’t, customers may never realize what you’ve shipped—or worse, they may feel confused, unsupported, and left behind.

Build it. Ship it. But don’t forget to market it, sell it, support it, and educate around it too.

Reid Hoffman famously stated the following: “If you are not embarrassed by the first version of your product, you’ve launched too late.” Far be it for someone like me to question the founder of LinkedIn, but I worry many PM’s follow this advice blindly. Hoffman’s sixteen word manta is valuable and I, too, live by it in my Product career. But with caveats…

I was launching a new product with a new team once. The product was going to fill a significant gap in the market. We joined a leadership call to announce the upcoming launch of our minimal viable product. The scope was ample but our excitement was met with uncomfortable silence across the zoom space we shared. Finally, a leader in Customer Success made a plea. He said, “It just has to work. It can’t let down our clients.” Apparently, there was some history here. Everyone else on the call nodded. Quality. Of course. Heeding Hoffman’s advice requires a short operating manual. Sure, release something embarrassing but with two interconnected caveats...

1. How will you be embarrassed? Will the product be slow? Buggy? Lack a bunch of important features? All of these things might be perfectly fine if you can figure out the second rule …

2. Who are you “launching” for? If you’re building something for your high-value clients and it fails, do you lose trust? Does your brand take a hit? If you’re launching to your old college roommate in a beta environment, perhaps their tolerance for imperfection will be greater. On the flip side, why seek perfection for a beta version you’re sending to users with low expectations?

In practice, I’ve learned these lessons the hard way throughout my career and now spend a considerable time convincing my clients to not launch a faulty v1 to the masses. Or, conversely, pushing out the launch of a v1 to the masses when it meets the customer quality standards. (I prefer the former option as I enjoy agile.)

Hoffman’s rallying cry is a good one. It pushes us to get product out into people’s hands, which ultimately leads to a better v2. Action over inaction. However, his cavalier quotation requires a small disclaimer lest we lose the trust of those we’re trying to please.

So, as part of ProductCamp Boston, I signed up for a workshop session and asked for volunteers to come help design a “CRM for Product People”. (It was a terrible, hookless title I admit, but selected nonetheless.) When I arrived at our assigned room, it was empty. And it remained empty until two PM’s in the investments industry joined me. Then, a pricing expert. Then, a PM for an actual CRM company! Lastly, an experienced PM who’s dabbled on the Product Marketing side too. We had a small but mighty team.

Lo and behold, I wasn’t the only one who struggled with this singular problem: “How do I easily assemble an insightful, concise 360 degree view of my customer?” I have been tasked with this in my last two client engagements and failed to find a good tech solution in each case.

It seems the data that we need remains scattered across various repositories. Sure, the CRM system has a bunch of fields and values, but it’s often too crowded to glean real insights. And I record all my customer calls but the recordings, transcripts, AI synapses sort of get dumped somewhere. Same with usage data. So, we asked, how do we collect this information and make the most of it? I had ideas going into the session but what my new Product friends brought to the table blew my ideas out of the water. I was shocked at both the consistency in our frustrations but also the diversity in ideas we garnered to fix this problem.

Ultimately, our ninety minute brainstorming session resulted in the following notes:

🧩Core Problems Identified

• Data fragmentation: Information is spread across different databases.

• Stagnant or untracked clients: Hard to track client engagement over time.

• Prioritized clients are difficult to monitor.

• CRM data gaps: Blank or incomplete information makes CRM data untrustworthy.

• Cost sensitivity: Price of current solutions is an issue.

• Low volume of customer insights collected.

🔐 Risks / Challenges

• Privacy concerns

• Sensitive data handling

• Adoption challenges (especially in capturing in-person interactions)

• Capturing offline or informal conversations
  

💡 Solution Concepts

• No manual data entry

• Use of AI (e.g., Gemini) to assist with:

  • Auto-generating a heat map of customers

  • Detecting patterns across attributes

  • Maintaining a news feed summarizing updates and notes

  • Breaking down silos so data is shareable and actionable

  • Identifying trends around needs

• Enriching each interaction with:

  • Intelligence

  • Headlines

  • Scoring

• Generate prompts with questions, personalized at:

  • The individual level

  • Aggregated across accounts

🎯 What to Capture

Qualitative:

• Customer pain points

• AI-analyzed call data

Quantitative:

• Versioning and product usage

• Firmographics

• Scoring based on:

  • Fit

  • WTP (Willingness to Pay)

  • Engagement data

• Open details and interaction sentiment

I’ve read through this list several times now, asking the all-important Product Manager question: “Where do we start?” If I were to build this, I’d start with something simple. I’d take the calls we’ve recorded, synthesize for insights, risks, feature requests, sentiment and then blend that with some basic CRM data. Maybe, as a stretch, I’d pull in some usage data too. The secret sauce, I imagine, would be marrying the data. Then again, isn’t that what artificial intelligence is supposed to afford us? Next, I’d build out a dashboard based on what our brainstorming team laid out. This solution would provide a rolling newsfeed for customer updates, a ranking top feature requests and a scoreboard for customer sentiment. Of course, there’s a lot more detail, but even this jumping off point would be a massive upgrade from what I’m doing now (which is coursing through this data manually). Best of all? It would require very little manual effort. Here’s an AI-generated image of the dashboard:

There’s likely a million companies that have built something like this, right? Maybe? I want simple. I want insightful. Most of all, I’d something purpose-built for the Product Manager. Am I alone?

Please share your thoughts in the comments, and let’s keep the brainstorming going. What do we need as PM’s? What do you use today to solve this problem? Is it enough?

🛟 Peril 1: Creating a category. The upside is huge. Imagine if we're first to market? We could own this thing! Well, sure. But likely there is no market for a reason. It may all work out but you have to be willing to invest several years into educating, activating the market. And then, you're doing the difficult category creation work for future market entrants. Creator beware. My analogy: This is like opting in to climb a mountain before climbing the mountain you really want to climb. You're selecting the harder path. Might be good if you have a long time horizon to success. Most don't.

🛟 Peril 2: Replatforming. I've fallen for this one several times. Heck, I've joined companies to participate in this type of strategy. It rarely works. Why? Most teams build a new stack from the ground up but rarely invest in the necessary migration tools or experience. Then, assuming the new platform is superior to the old one (a farfetched bet), the customer is left owning much of the work to migrate. It'll beg the question for the client: Should we consider other vendors given the effort? A better way is to swap out just part of the platform that's causing issues (for example, a new UI for usability problems or a new service layer for performance issues). My analogy: Imagine you own an island in the sea where your customers live. The island is good enough but surrounded by risk (sharks). You invest in a much nicer island that your customers can see but not easily reach. They'd like to come over to the new location, but aren't sure if they have the ability to. Wouldn't it be better to throw the client a raft? Better yet, build on the island they're already on?

🛟 Peril 3: Chasing a new market or market segment. Sure, at some point, you might be left with no other option to grow through catering to a new audience. However, a lot of teams make this move too early, building a new product for a new audience rather than continuing to support the audience that already trusts your brand. My analogy: This is like hitting a fork in the road and opting to head down the path with less travelers, hoping to reach a larger population in the future. Find your tribe and travel with them.

What did I miss? What might you disagree with? Have any war stories of your own in these areas?

In this episode, Sean describes why Whoop is his favorite product, how it helps shape his behavior and why a stronger platform play can remove friction in the product experience.

Here’s the story. About a year ago, we set out to build something new. Most of our early specs were built around our CEO’s vision, which we agreed was enough to build around (okay, possibly swayed by the fact that he was paying us all.) For a few months, we tinkered with a demoable product that included an interactive front end built on hard-coded, static data. This approach would allow us to put a seemingly functional product in front of people to garner feedback in a demo environment. This pre-sales development strategy, in hindsight, was a very good decision. It saved us engineering cycles and allowed us to change the product quickly without risk.

We also made a poor decision. When we built our new product, we made a critical decision early on. Instead of building a new product for our current customer base, we’d attack a tangential market segment in which we didn’t have a foothold. The new market segment was much larger and provided more financial upside in the longterm. I had interviewed dozens of folks from our current customer base, and many were interested in what we were building. Alas, we were more interested in the bigger market, despite the fact that we were a smaller company without the pressures of investors, public or private.

So, we ventured into the unknown and attempted to chat with target buyers/users from the new market. Despite investing in SEO and social advertising, we couldn’t attract anyone from this new segment to get on a call with us. Many of us - including myself - reached out to folks in our personal network to source interviews. In short time, the well ran dry. In this new market, we lacked an Audience.

Our friends and family demos provided us some feedback but as any Product person knows, it takes real users using the product to assess true product-market fit. We opened up a beta program in November 2024 and ran webinars to introduce the program. Our goal was ten by the start of 2025. No one came. As of this writing, we are at zero beta users. It hurts.

“Build it and they will come" they say. I truly believe that the problem we’re solving exists and there is a market for it. However, we started in the wrong place. We had an Audience of trusting customers that had done business with us for years and had a need for the solution we were building. We looked past them at a bigger market in which we hadn’t built a reputation, a brand or trust. (Okay, fine, I will queue the meme now.)

An Audience is a significantly valuable asset that can take years to nurture and build out. Hubspot was able to grow their Audience around the “inbound” movement. Wes Bush and team have built an Audience around “product led growth”. It wasn’t done overnight but was accomplished with helpful, genuine content and a firm POV.

I feel we’ll pivot and head back home, asking our current customers to assess the product. It will require some tweaks to the product to make it usable for this group, but it’ll be worth it. We’ll learn from this audience, earn social validation and can consider expanding to the larger segment down the road.

(I suppose now would be a good time to thank you for being part of this community here at Build It, Ship It. Thanks for reading, thanks for sharing, thanks for engaging.)

At each stop in my Product journey, I’ve started a user group. Most companies I’ve joined hadn’t thought to do this. Essentially, I create a program in which customers may sign up to be part of our development process. Once on the list, customers will be invited to release previews, design reviews, surveys, customer roundtables, etc. Of course, the customer can attend all, some or none of these events. For the customer, this is a huge win because it provides them the opportunity to influence our product direction. For us, we win because we get closer to our customers, collect their feedback and earn their trust. The user group, as simple as it sounds, has been my most successful tactic at building and strengthening an Audience.

I’ll leave my client engagement proud of what we built, and hopeful that the product will resonate with a small group of folks. I’ll also leave this engagement having learned a hard lesson around embracing the community that you have access to. Embrace the community that trusts you.

“Dance with the one that brought you”, I’ll say.

My thesis? Most PM-PMM collaborations are broken by what I call the “Relay Model”. In this approach, Product Management creates the roadmap, builds some stuff and hands off to the Product Marketer to bring to market. Instead, what if PM and PMM came together to discuss positioning and product strategy and then crafted a roadmap together? What if the two teams worked hand in hand on a launch strategy to capture value? Of course, folks could break off to execute on the tactical work as needed. I call this model “Convergence Divergence Model” and I think it works better.

But what do you think? Is this something that’s truly a problem in most orgs? If so, what’s a better model? What have you seen work for healthy PM-PMM working relationships that drive organizational value? Your feedback will inform a future longform article on this topic. Thanks!

Watch the full episode here!

1. Defense

2. Defense

3. Scoring

4. Defense

Perfect. I was a good defender. During the tryout, I blocked several shots, deflected balls and all-in-all proved to be a pretty scrappy defender. However, I wasn’t athletic enough to be a prolific scorer on the other end of the court. I didn’t make the team. For years, I have tried to do the math in my head to understand the coach’s process. I always come down to the same realization: That coach was lying to himself.

I’m the fractional CPO at this small company and we’re trying to launch a new product to a new market segment and - like any new entrant - it’s hard to find a foothold. We’ve tried it all on the marketing side: organic content, paid search … lists (I know …). Traction has been hard to come by. We’ve been trying to do things the right way, launching a beta program and inviting the world to partner with us in the feedback loop. This way, we won’t build to the ideas in our head but to real customer feedback. We have zero beta participants as of today.

To keep our spirits up, we talk about the future and the long-term product vision. We celebrate small wins with product development, though we don’t have many prospects to bounce ideas off of. We have been trying to do this the right way for so long.

This week, we had a breakthrough. Our sales rep laced the new product into his talk track for our flagship product. The persona for the new product is different, and we historically didn’t want to risk losing an opportunity by muddying the waters. But the cross-sell attempt worked. The customer understood the use case and agreed to include another team in the evaluation. We now have a larger opportunity for a bundled offering. Swish.

Like a barnacle on a ship, I’m clung to this deal. I am at the ready to build any content our Salesperson needs to move the customer along. I’m rethinking pricing for the bundled offer. Do we run the risk of building/repricing/messaging based on the feedback of a sample of one? Sure. But we need a win. And to win, you have to score. Chasing one-off sales may be a certain path to product hell but God knows our team is going to chase this deal. Why? Because we want to score. We want to see a number on the scoreboard. We want these points to motivate the team to score more. And scoring, as a matter of fact, is what wins games.

I once worked for a CEO that claimed the company had two roles: Sales and Sales Support. Most Product folks would roll their eyes, but I love it. If you’re a for-profit company, isn’t this the ultimate goal after all? I realize it sounds superficial, cut throat, like a scene out of the movie “Wall Street”. But at least it’s honest. We’re not lying to ourselves.

(A quick sidebar: What is “defense” in this analogy? I suppose it could be protecting your advantage from the competition. Or it could be keeping customers happy above all other things to retain revenue. You could argue that either is more important than scoring. However, the market still loves revenue growth. Revenue is validation of a market and your ability to consistently penetrate that market effectively.)

My kids play basketball year round. Every now and again, they’ll play quite lousy, turning the ball over, committing needless fouls, etc. However, in the same game, they could take a few shots that go in the basket. And all their previous infractions are seemingly forgotten. Points, of course, aren’t all that matter. You do need to stop the other team from scoring. Even on offense, you need to set up scoring opportunities (“sales support”). But let’s not forget to shoot. It’s how you score. It’s how you win.

But I would have been far better off had I been required to deeply research my product. Not in “what” it can do (as most of my career stops have required me to learn) but "why” the product exists. Here’s my idea: Let’s pretend each of us had to write a two-page essay in our first month. The essay would have been called “Why We Win” and its thesis would have captured how our product wins in the market. We’d have no choice but to make friends fast, interviewing various teams to get their understanding of how we compete in the market. It would force healthy discussions with leadership and cross-functional peers. We’d have to pore over sales notes and online reviews to figure out what people love about our offering. Ultimately, we’re going to land on the most critical aspect of Product Management I’m aware of: The differentiators between our product and everyone else.

Now, here’s the catch. Only the first page looks back. The first page talks captures how the market sees us today. The first page talks about why customers repeatedly use the product and ideally share it with friends.

It’s the second page where things get interesting. “Why We Win” turns to “Why We’ll Win”. Now, the paper becomes forward-looking. Perhaps we’re happy with steady growth. In this case, we’ll win because we’ll defend our position and we’ll accentuate what we do better than anyone else. Perhaps we’re laggards in the market. That’s okay. Maybe we’ll lean into our differentiators and put effort toward educating the masses of its importance. Or - we’ll focus on developing around new differentiators and hope to capture more market share through this new path. Or - we don’t know yet why we’ll win, but here are five things we’ll try as a way of getting to that answer. Or - who knows? Page two could go in so many directions. Whatever the case might be, page two is a journey into the future, built on the historical reflections from page one.

The second page now becomes the product roadmap which, as we all know, shouldn’t be a random collection of features but a path toward a larger product vision. The product roadmap should map to a go-to-market roadmap that leverages product develop to capture more value in the market.

I imagine this essay being the guiding line for the new employee, and a helpful playbook for existing employees. Imagine this essay being edited by company to ensure its accuracy. Imagine a team of developers or marketers (many of whom contributed to the essay) reading its contents and fully understanding the direction of the product.

We often get lost in customer requests, JIRA tickets, old powerpoints, competitor press releases. Instead, we should turn our attention to intention. If we take a disciplined approach to why we’ve won in the past and what that means for the future, we have a better chance of aligning the business around a common strategy.

One last catch - the paper isn’t a static artifact. It’s a living document that the team can periodically update as it learns more and the world changes. However, in its first iteration, its a pretty good way to start a new Product gig.

As we close out 2024, I’ve been thinking a lot about “positioning”. How do companies brand themselves in a larger market context? What sets one company apart from the others? How might a company position its offerings in the market to maximize revenue potential?

Most B2B companies I’ve been a part of have struggled with this. Some fail to identify a characteristic that stands out. Others have lost their way and attempt to pivot to a new position only to lose their old identity altogether.

When I hear the word “differentiator” (as a way to position a product or company), my mind immediately goes to software features. Admittedly, my background is in SaaS software. So, most of the time, our offering is the product. And the product is competing savagely with other products in the space that often look a lot like each other. Sales bake-offs start to resemble a battle of feature check lists, or companies drive prices down to attempt to be differentiated on price. From my experiences, many companies have a clear differentiator that isn’t a feature or price. And they completely fail to position around it! I’ll discuss what that differentiator is in a moment.

Features are hard to differentiate around. For one, technology is relatively cheap. So, in most cases, your competitors can quickly catch up to your differentiator if they’d like. Or a wave comes along that provides access to new differentiation. Mobile. Social. Cloud. AI. When there’s a gold rush, software vendors will instinctively pick up a shovel and head west. It’s simultaneously an offensive maneuver to innovate before rivals but also a defensive tactic to ensure that no one will do the same to you. Eventually, everyone starts to look like the others.

Positioning is hard. Of the several companies I’ve worked at, only a couple had a clear internal positioning strategy that translated to clear messaging in the market. Perhaps the best I’ve experienced was Virgin Pulse, a company that provides health and wellness experience to employees at large companies. Virgin Pulse set out to create partnerships with myriad wellness apps that were extensions of its own offering (reward system for completing wellness activities). This became the “homebase for health” strategy in which customers could enjoy one-stop shopping for employee wellness. It was a platform play and it worked.

For every company I’ve been part of that had clear differentiation, I’ve seen as many companies that lacked differentiation. I’d often seek our sweet spot. I’d ask, “Why do our customers stick around? What do they like about us?”

The answer, in quite a few cases, was a clear differentiator many companies overlook: customer support. To be clear, I don’t mean a 1-800 line or an AI agent trained on your knowledge docs, I mean a real, human partner. I am referring to dedicated account ownership. For a few of the smaller companies where we lacked feature depth, customers loved the human support they received from us. Yet, software vendors often source the very best in customer success and bake into their operational models and then fail to market this core asset that customers love. Customers find solace - and ultimately success - by picking up the phone and speaking to a live, knowledgeable human they’re familiar with.

Why don’t companies highlight this differentiator? Many companies are fixated on feature differentiation and fail to position world-class service. Sure there are better products than Acme Corp. But at Acme Corp., I can always call Jane or Bob or Harry or whoever I am used to calling and get resolution of my problems. I have a strategic partner on the inside.

From my experiences, support also becomes an afterthought in the pricing and packaging or a throw-in. Or worse, there’s a made up level of support that gets added to the premium version of tiered pricing while the high-value support that all customers get is undersold.

The solution? Treat service like a feature. Speak to its value. Write case studies around how support partners have helped clients in the past. Heck, introduce prospects to their potential support rep pre-sale.

Support may not have the appeal that a new, shiny feature has, and features are still critical to a customer experience. While the rest of the industry is fighting over features, prioritize (and maybe differentiate yourself) based on a very enticing value proposition: human interaction.

When I started my own agency, I wanted a name that captured not just what we did but the part of this work I enjoyed the most. Admittedly, the "Ventures" part of the name sounded good. But the "Breakthrough" part was a necessity. It accurately describes the value I bring to teams.

At each stop in my career, it was the breakthrough moment that catapulted the business to new heights. In many cases, it was that moment when the team felt lifted, inspired around a new mission.

Here are a few examples.

💡 At Dun & Bradstreet, we wanted to launch a new product. We set off to build a slick, feature-rich experience. But it was the wrong approach. After several weeks of speaking with prospects, we learned it was the performance (speed, scale) that they wanted up front. Those were the features our clients cared most about. It was the basics, not new features that just seemed cool. We won. We launched. We sold a seven figure contract in our first three months and many others.

💡 At SugarCRM, I inherited a product in a cutthroat battle with other marketing automation tools. Small but mighty, we tried to match our competitors feature for feature. Yet, we hemorrhaged customers. We were playing the wrong game. We switched our market to clients looking for basic functionality at an affordable price that worked really well and played nice with the CRM. Once we had that breakthrough moment, our fortunes changed. Client retention turned around.

💡 With a current client, we had been building on a path to provide a new product experience that could help sellers close more business. We demoed the product prototype dozens of times. The breakthrough? The UI helped the audience understand the need but helped us understand our product was wrong. Sellers really wanted a simple messaging service, not a fully baked UI. We pivoted and are having much better product-market fit conversations.

How did these breakthrough moments happen? I think there were three major factors that led to a game-changing breakthrough. As you’ll see, these factors aren’t mutually exclusive.

1) Customer interaction. In each case, the breakthrough moment required chatting with real customers. It's an art and a science. I love this part.

2) An open-minded, egoless team. Each breakthrough required a team that could be open-minded about the future. No one was too married to an idea or afraid to let go of an idea that previously was thought of as infallible.

3) Curious leadership. While the team may be willing to wait for the breakthrough, it’s typically one person at the top who will chase it. It required someone who can ask the right questions and dive into the data with restless abandon. I’ve historically fulfilled this role in several cases. Of course, I can't claim full credit for these eureka moments. I was simply the sherpa that helped the team climb the mountain. And I love that job.

If your team feels stuck with its Product direction, execution or strategy, keep in mind that many companies go through something similar. Here’s a mantra that might help: “The right answer is attainable if we care enough to never stop chasing it.”

This morning I read that the new movie “Joker: Folie à Deux” could lose up to $200M due to poor box office performance. How could this be? The film is a sequel to a huge hit. The film includes two of today’s largest superstars in Joaquin Phoenix and Lady Gaga. The characters and storyline are spawned from the superhero universe which typically guarantees success. Yet, poor reviews lead to poor box office turnout and eventually the film can’t catch up to its giant budget.

So, what does this have to do with Tech? Risk mitigation. When we’re building a new product or feature, we have this amazing tool at our disposal: Prototypes. We can throw this in front of customers, get feedback, and then take action. The best part? This tool can be leveraged multiple times (even with the same customer) with the only real expense being time. We have the luxury of reading the pulse of our customers while we make the thing that they want.

Now, imagine if Todd Phillips (the writer, director and producer of the “Joker” sequel) brought his customers through the making of his movie? You’d get mixed results, you’d get leaks of the plot and you’d only add to the enormous budget if you were forced to rewrite the script, etc.

For movie makers - similar to a lot of art - you are forced to go “all in”. In the world of project methodology, this would be labeled “waterfall”, or building a product in one shot, covering all requirements before delivering the product to its intended audience. While necessary - or even preferred - in some industries, waterfall is risk laden whenever there’s uncertainty in audience reception. Waterfall tends to work better when the final output has been clearly agreed upon by the client and customer.

The Batman to waterfall’s Joker is “agile”. Agile methodology has many virtues and perhaps at the top of that list is risk mitigation. By checking in with the customer throughout the development of the product, success is defined and redefined to increase the probability that the final result is viable.

In my career, I’ve practiced both styles. When I started my career in classical project management, waterfall was the default mode. However, as I transitioned to Product Management, teams I had been part of did come across projects where there wasn’t much question what the result would be. For example, we needed to increase performance of one of our core services once. We had tested one data management system for performance and then decided to move forward and swap out our old system. We’d meet everyday, plan sprints, groom tickets and have retrospectives to talk about the previous two weeks. Most of these meetings were dull and predictable. Eventually, I asked the team if we should just do waterfall. The team was paralyzed by my question at first but as we discussed it, we realized it would save time and get us to the finish line faster. The project went great and customers loved the results.

However, the vast majority of initiatives I’ve been part of have been classic agile. I’ve seen one large differentiator between teams that do agile well and those that don’t. The best teams truly do include the customer. As product evolves, the team frequently engages with the customer to gauge their reaction. Conversely, some teams don’t do this. It’s not because they don’t want to. It’s because it’s really freaking hard. Organizing the customer interviews, fostering client relationships, setting up the framework for feedback takes time and effort.

Agile - when done well - gives Product teams a tremendous advantage. Sure, we may not be producing blockbuster movies, but - with some effort - we can produce a Hollywood happy ending to our own story.

I started in a fractional Product leadership role in February. Upon joining I felt an intense amount of backlash, territorialism and distrust from the Engineers. Still feel it today to be frank. As a New Englander, the analogy I make is that it felt like leaving the warm confines of my home on a January day and stepping out into windy, bitter cold. It stings.

Before long, I realized that the team had their own way of doing things, including a roadmap. I didn’t stomp my foot like I wanted to. Instead, I asked to see it. I wasn’t surprised to witness what looked like a copy and paste from a JIRA backlog. It was a list of stuff in no particular order with no obvious business value. It was in a google sheet. It had links to JIRA. It had ugly color coding and different fonts for labeling. I attempted to coach the team on standard roadmapping approach but I didn’t get far. I closed their roadmap quickly and set out to create my own proper roadmap as I had every stop in my career.

Then, something strange happened. I didn’t create a new roadmap. The Engineering roadmap still exists and they quite like it. Customers never see it, nor does anyone at our company outside of Engineering. It’s not a roadmap, as we all know.

I realize that I could create a real roadmap, walk the team through it and slowly get buy-in. Or just operate with my own. But I realized I didn’t need to. We have 3-4 big things that we’re building and we share that update with clients. We have a couple of slides on each that speak to the value. We alert them that those items are on the short-term horizon. Everything else is a candidate to make the short list of 3-4 big things and we try our best to track how often customers ask us for those things.

We are getting by fine. We’re not contractual with customers. We’re confident. We focus on the big boulders and lean into their value rather than dance around 30 features spread out across timelines that rarely pan out at most companies.

This model works for us. Full disclosure: We’re a very small team and a small business. I understand that at larger companies the roadmap is a tool for Sales teams to paint a picture of the future or prove to clients that their needs are in the development team’s plans.

But I’d ask you to at least consider how vital the roadmap really is. How much time do you spend laboring over dates and priorities? Instead, what if you leaned harder into the “here and now” features? The here and now has a higher probability of deployment. The here and now is looking for beta customers. The here and now is innovation capital, especially if you can demo something, even a mockup.

If you can demonstrate the here and now with conviction, speak to the items you’re considering for the future, and paint a vision (not a list of features) for the far-out future, what more do you need?