Tag: product development

I like meeting with early-stage founders as a technical consultant. It started a few years ago when I went through Venture School—a program run by the University of Iowa JPEC. I had an idea for a startup and spent eight weeks learning how to vet it properly: market segments, supply chain, financials, the Business Model Canvas. All the disciplined thinking I’d never done before.

What I learned over those eight weeks killed my idea several times.

Each week, I used what I’d learned to pivot, improve, or reshape it until it was viable again. That process taught me something I still come back to: the first, second, or third problem with a concept isn’t the end of the discussion. It’s the beginning of product development.

How About This?

Fast forward to this week. I met with two co-founders building a media-discovery app. Like Tinder, but for finding your next book or movie based on what you already like.

Cool, I said. Most “you might like” systems—Goodreads, Netflix, the rest—are better at recommending what they have in stock than what the user will actually enjoy. Late-stage capitalism meets less-than-motivated data science. Any idea that genuinely re-centers the user has my attention, so we were in violent agreement.

They had a slide deck, some mocks, and friends-and-family funding lined up. What they wanted from a technical partner was help figuring out how the AI and recommendation engine would work.

That is the product, I said.

TikTok isn’t compelling because of the videos. It’s compelling because it almost never suggests something you don’t want. It learns fast from misses. It connects seemingly unrelated interests across users and surfaces things you didn’t know you’d like. That’s the entire value proposition—and it’s also the hardest part to build.

What these founders had was a clear idea of the outcome they wanted. What they didn’t yet have was a plan for how the product actually gets there.

We ended the call on friendly terms. I’ve seen this moment enough times to recognize the pattern: the team is motivated, capable, and persistent—but persistent in a way that treats the idea as fixed and the execution as something that will sort itself out. In my experience, that’s usually the fork in the road where things get very expensive, very slowly.

The Hard Part

This isn’t really about technical skill. I see the same thing with non-technical founders and deeply technical ones.

It’s about falling in love with your idea.

Your big idea is probably not original. It’s also probably not where you’ll end up. And it’s almost certainly not the hard part. The hard part is the disciplined work of product development: market segmentation, competitive positioning, unit economics, customer acquisition, go-to-market strategy.

That’s why the Business Model Canvas exists. It forces you to examine an idea from every angle before you’ve spent two years building something nobody wants.

I recommend the Canvas to almost every founder I meet. Very few take me up on it.

Not because they’re lazy or unserious—but because being that critical of something you’re excited about is genuinely uncomfortable. It requires you to treat your idea as a hypothesis, not a belief. Most founders skip that step. And most of them pay for it later.

The parting advice I gave these founders was to spend a few weeks building real domain expertise. Talk through the problem space deeply. How do we categorize media? What’s already been tried? What technical approaches exist for recommendation systems, and what trade-offs do they make? Where do they fail?

Whether you use Claude or textbooks or interviews doesn’t really matter. What matters is developing a systematic roadmap to engineer the thing you imagine—or discovering that the thing you imagine isn’t quite what you should build.

They nodded politely. I hope they prove me wrong. But I’ve learned to trust that signal.

The Same Pattern, Different Domain

Later, it occurred to me that I see this exact same dynamic play out with teams choosing tools.

Someone falls in love with Cursor, or Slack, or the latest AI-powered development environment. The tool becomes the idea—the thing they’re excited about, the thing they evangelize, the thing they’ve already decided to adopt. The disciplined work of understanding their actual workflow gets skipped entirely.

How does work move from concept to shipped product? How do tasks flow from planning through development through deployment? Where does information get lost between systems? Where does ownership get fuzzy?

Those are product-development questions for your toolchain. Most teams never ask them.

Instead, they bolt shiny tools onto whatever they already have.

That’s how you end up with Jira for planning, GitHub for code, Slack for communication, Jenkins for builds—and no clear answer when something breaks at 2am. No single source of truth during a security review. No shared understanding of which system is authoritative when timelines slip or releases stall.

Nobody designed that workflow. It accreted, one tool-crush at a time.

Falling in Love With Shipping

We built GForge Next around a deliberately unsexy premise: the tool should disappear into the workflow, not become the workflow’s main character.

Integrated planning, code management, and deployment tracking aren’t flashy. They’re not meant to be. For teams that have moved past falling in love with tools and want to fall in love with shipping instead, that’s exactly the point.

If you’re ready to stop bolting systems together and start building product, give GForge Next a try. It’s free for small teams and open-source projects.