I just came off ShipKaro, Wajahat Karim's weekend cohort, and it was genuinely amazing. I went in mostly to see the culture around it. The interest behind actually building something, and how Wajahat is leading that change here.

Because for a long time in Pakistan, the path has been one thing. You get tired of your job, you go freelance, then you open an agency, then maybe you build a product. And I'll own my part in this. I've pushed that exact path to a lot of people.

I still think it's the right one if you're going to launch a B2B or SaaS product. You need those experiences to compound. Freelancing teaches you clients. An agency teaches you operations. By the time you sit down to build something, you actually know what you're doing. That flow is real.

But there's another path I kept walking past. Indie hacking. Saad Pasta first put it in front of me, and now Wajahat is pushing it too.

Indie hacking, the way I understand it, is building micro-SaaS. Small products that solve one use case really well, set you apart, and yes, you can put a price on them and earn from them. I'm not an expert. I'm not going to pretend I am. But it cracked something open. It's a perfectly good alternate path, especially if you're a developer, or technical enough to understand how software actually works underneath.

And with the AI tools we have now, you can genuinely build an app that solves a real problem well. Which is exactly what I'm doing through the cohort. I'm building a to-do app for myself. No plans to monetize it. It's the same capture-first thing I've written about before. I'm building it because I want it to exist.

The bigger thing sitting on my mind is my teaching. I think it's about to change.

The people who usually show up in my server, The Wandering Pro, are mostly at the stage where they don't even have the skill set to land a job yet. So I can't really reach them with this idea, not right now. The long-term goal is the people one layer up. The ones who already have a career, already have a job. For them, freelancing isn't the only answer anymore. Remote work isn't the only answer. You can build your own app, your own small product, your own thing. That's where I think this is going, with AI quietly lowering the floor.

I don't want to be the guy saying it's easy. It's still hard. But AI has made it accessible enough to at least get in the door. And building cool shit is what mattered all along.

Which is where the actual crisis shows up.

I was talking to my wife yesterday and I asked myself out loud, what do I actually love? Because my plate is already full, and somehow I still joined a cohort and started building a mobile app. There is no version of my schedule where this fits. I know I can't keep it up for long.

But when I line up my past, my present, and whatever the future ends up being, the answer is the same every time. What I love is building stuff. Some of it works, some of it flops, some of it dies quietly. Who cares.

Here's the part that stings a little. Almost everything I've built has been on the services side.

In the last 3 years alone I've stood up more than 4 agency fronts for partners across the world. Australia, the UK, Nepal, the US. Because I know how to put together a landing page that converts. I know how to set up the operations to run a services business. I know how to coach someone through getting clients, making sales, writing proposals. That's paid my bills, and it's the network I've been quietly building, because I never had a referral network so I went and made my own. I took people who were sitting around and pushed them into starting their own services businesses.

So the question I can't shake is simple. Why can't I do the same thing for products? For apps?

This is the identity crisis talking, and I'm just logging the rambling.

The Wandering Pro was always meant to log the bigger journey. I started a career. Got good at it. Escaped it. Went into freelancing. Got good at that too, ended up one of the better product manager freelancers on Upwork out of Pakistan, even ended up working at Upwork itself. Which is a badge of honor I should probably wear more openly instead of tucking it behind me. Then I left freelancing and started the business. And for the team size we're at and the margins we're running, we're doing alright. First year was decent. The second is shaping up to be better.

I told Wajahat something over chat. One thing I realized after starting the business is that I have almost no local presence. Not the way he does. I haven't done talks. I haven't done any speaker stuff. That's probably the biggest gap right now, and it's going on the roadmap.

And I told him why, sort of. I'm a product manager by trade, and we are terrible at being proud of what we do. Imposter syndrome is our resting state. We're such generalists that we never feel good enough at any single thing. That has to change. I need to start saying the things I've actually learned out loud.

Because here's what I keep getting wrong. When I look at the people in Wajahat's cohort, or the people in my own community, I set the bar way too high for myself. For my personal life, for the business. And the ground reality, the thing literally written on The Wandering Pro about page, is that most people are just trying to pay their bills. Most people don't want $10,000/month. They want sustainable, scalable income, earned in a way they're actually proud of. Not grinding their soul down at a job they can't stand. That's it. That's what most people want.

Freelancing can be that answer for a lot of them. Starting a business can be that answer for a lot of them. And now I think indie hacking and product building can be that answer too.

And this isn't just my eyes opening because of one cohort. When the year started, I launched Wander Labs inside the community. Same idea underneath. The Wandering Pro is me logging my own career. Good at the job, then good at freelancing, then good at business. I'm still in the middle of getting good at business, I won't pretend I've arrived. But the start is solid.

Eventually I want to get to the product side properly. And I have this habit of setting lofty goals. Mine has been, I'll only build a product when I've got $1,000 sitting in a bank account I can comfortably bootstrap with. Watching Wajahat, I think that rule might just be a me thing. I like doing things at a certain standard, sitting here in Pakistan. That's my baggage, not anyone else's.

Other people don't carry that goal. They don't need to aim that high. They don't need to shoot for whatever I'm shooting for. So maybe my job is to help them reach the goals they actually have, the ones that aren't sky-high. And that's completely fine, because I've done enough by now to have something worth handing over.

The biggest thing the cohort knocked loose was this. I used to believe I had to be ultra, mega successful in Pakistan before I had any right to teach. That the proof had to be enormous. Turns out that's mostly vanity. What actually matters is much simpler. Do you know your shit. And do you have some proof that you know it. I have plenty of proof. The Upwork profile, the monthly retainers I've sold for up to $10,000/month, the actual work. The capability is here. What's left is opportunities, and those come and go. That's just how it works.

So this entry on the Rift is the identity crisis one. That's the name. And really, the whole blog is named after exactly this. The Rift is the constant pull inside me between building things, helping people, running a business, running a publication, and writing about all of it at once. That's the rift I'm always juggling.

I think this is the defining piece for it. The one that finally explains the name.

Still figuring out which side of the rift is supposed to win on any given day. Probably all of them. Probably none of them. Ask me again at the end of the year.

With or without my help – I wish you the best.

That sentence still feels strange to type. I've spent the better part of a decade around software without building a single piece of it myself. I've managed maybe two hundred projects. Written the specs, run the discovery, argued about scope, shipped other people's code. I never once sat down and made the thing.

Now I am. I wrote about what it is over on The Wandering Pro. A capture-first task app built on a small system called CORE. Capture, Organize, Review, Execute. That post is the what. This one is the why underneath the why. Because the app isn't really the point. The thing that walked me to it is.

The thing is first principles.

I reduce almost everything to its fundamentals before I touch it. That's the whole move. You take something that looks complicated and you keep breaking it down until you hit the part that doesn't break down any further. The plain, common-sense version of how it actually works. And here's what I've found, over and over. That part stays still. The tools on top change. The frameworks change. The flavor of the year changes every year. The fundamental mostly doesn't. Sometimes it doesn't move for decades.

That's why they're called fundamentals. I take the word seriously, because most people don't. Every course guru slaps it on a slide. Master the fundamentals. Okay. Which ones. A fundamental isn't a buzzword. It's the plain truth left over after you strip away the branding someone built on top of it.

Here's how this shows up in my actual life. I'm not a developer. I'm not an AI expert. I don't read manuals cover to cover, and I've never finished a tutorial in my life. The only way anything has ever gone into my head is by doing it, breaking it, and figuring out why it broke. Learning by execution. And the reason that works is first principles. When you try to do the real thing, you're forced to scale it back to the smallest piece you can actually understand, then build up from there. You can't fake your way down to the fundamentals. The doing drags you there.

Let me give you the example that made this click.

For years, people in my community asked me the same thing. What's your system for managing all of this. What's the framework. I never had an answer. I run a business, a publication, a community, a consulting practice, and a life, and I juggle all of it. When someone asked me how, I'd shrug and say I don't really know. I'm just kind of okay at it.

Then someone sent me an article about a productivity system called CORE. I read it and my first thought was, oh. That's just what I already do. I'd been running a named, written-about, taught-to-thousands system for years without knowing it had a name.

That's the whole thing about fundamentals. When you reason your way down to the sensible way to do something, you often land on the best version by accident. Not because you studied a framework. Because you thought it through from the bottom. Then someone better at marketing writes a book on top of that same sensible thing, gives it a name, adds their flavor, sells it. The framework was never the magic. The framework is just a fundamental with a cover on it.

So here's how the app happened.

I'm sitting with this realization that I've been doing first-principles task management for a decade, and the natural next thought arrives. The apps I use for it are all bad at the one part that matters most. Capturing a thought before it's gone. So why don't I build the one I actually want.

The old answer to that was always the same. Because I can't code.

But that's not a fundamental. That's a tool problem. So reduce it. What does building an app actually require, underneath. It requires figuring out the right thing to build, then building it right. That's the oldest problem in software, and it hasn't changed in my entire career. The first half, figuring out the right thing, is the part I've done professionally for ten years. The second half, building it right, was the wall I kept bouncing off. The syntax. The setup. The thousand small things that make non-developers quit.

That wall is the part that moved. I wrote about it when I built this site with an agent, and again when I finally built a brain. AI took the execution tax and made it small enough that someone like me can get through it. Which means the only thing standing between me and an app was the half I was already good at.

So the decision to build wasn't bravery, and it wasn't a midlife thing. It was just first principles. The fundamental of software is still figure out the right thing and build it right. One half I own. The other half got cheap. Of course I'm building.

I'm calling it enCORE. An encore, sort of. Coming back to do the one thing I'd circled for a decade and never done.

I want to be honest about the other side too. Maybe it flops. Maybe vibe coding carries you to a prototype and then collapses the second you need something real, shipped, on a store with your name on it. Maybe a non-technical guy can't actually do this yet. That's genuinely one of the things I want to find out, and I'd rather find out by trying than by reading ten more threads about whether it's possible. The app is half the point. The experiment is the other half. If you can think clearly, and the tools have finally caught up, can someone like me ship a real thing. I don't know yet. I'm going to go find out.

If I'm honest, first principles is the quiet engine under everything I do. Relentless execution. Ruthless prioritization. Ravenous curiosity. I say those a lot. Under all three is the same boring habit. Reducing things to what's actually true before acting on them. Prioritization is first principles applied to your time. Execution is first principles applied to a plan. Curiosity is what keeps dragging you back down to the fundamentals when everyone else is content with the surface.

It's the least sexy skill I have. Nobody can sell you a course on it. The moment you actually have it, you stop buying courses and start reasoning things out yourself.

So I'm building an app. Not because I suddenly learned to code. Because I reduced the problem far enough to see there was nothing really stopping me. I'll be documenting the whole thing as I go. The good, the broken, and the honest answer to whether someone like me can pull it off.

With or without my help – I wish you the best.

About four or five years ago, give or take, I started using AI meeting note takers like everyone did. Fathom was my pick. Not Otter.

As someone who used to manage 30+ projects at a time, having a tool that recorded all my calls, summarized them, and transcribed them was really helpful. This was before all the LLM stuff was on tap. I still had to manually curate insights and bookmark timestamps. But having a record of voice as text was huge. It's much faster to scan through than going back through long video recordings.

Fast forward to now. We have AI tools. And sometimes it feels like typing is just too hard. The flow keeps breaking when you're trying to talk to an AI tool by typing.

The thing I've come to understand is this. AIs are really good at taking a ramble, a stream of half-formed information, and turning it into steps and actions and processes. That's just how they work. Garbage in, garbage out. If they're tuned right, hopefully garbage in, sensible stuff out. That's the whole game.

So a couple of months ago I started doing something different in my usual task management process.

Brief secret. I'm a big believer in the C.O.R.E. task management process. Capture, Organize, Review, Execute. (Maybe I'll write about that one another time.) The first step is Capture. And for someone juggling as many things as I do, when something comes up, it needs to get captured immediately. Zero lag.

For the longest time, what I'd been doing is just using chats. WhatsApp or Slack. I always have a thread to myself. For example, if I'm working with a client and I'm in their Slack, there will be a thread to myself in there. So if a task comes up related to that client, I quickly drop a one-liner. Whatever the action item is. And per the CORE philosophy, I sort it out later.

So Capture is really important for me. That step has now evolved.

I've gone from one-liner notes to voice notes. Largely because Slack's transcription is genuinely good now. So when I have an idea, like the idea for this article that I'm voicing right now, I just open a voice note in Slack and record. My Slack is full of voice notes to myself.

I have free Slack, so it's limited to 5 minutes per note. Which actually works in my favor. It constrains me to think a bit more structurally.

Then there's this very popular tool called Wispr Flow. Every AI bro out there is using it to maximize their gains. Unfortunately, I couldn't make it work. As I mentioned in my last post, I'm an ecosystem-agnostic guy. That tool didn't play well across my ecosystem of two phones, three computers, and a bunch of web and local stuff.

One thing I recently started doing. Inside VS Code, the Claude Code extension now has a mic button that does exactly what Wispr Flow does. For free. I don't really need to add another subscription to my life.

So these days I'll be sitting there, talking into a mic, for an oddly, awfully long time. Which is kind of weird.

The biggest annoyance is this. I run a community, and I'm usually working live in a co-working space inside my Discord server, on a voice channel. Now I have to constantly mute and unmute myself when I'm talking to the transcription thingy. Mute. Unmute. Mute. Unmute. Repeat.

But all of this to say. The highlight is this. People who are good at talking out their thoughts are going to be the most effective with AI workflows. That's just the world we live in.

On the other side, I've seen people who are bad at thinking out loud. They struggle with this a lot. They ramble and ramble and ramble. And then it becomes a real garbage-in, garbage-out situation. You still need to be precise. You still need to be structured. The tools help, but they don't replace the thinking.

It's clear though. Typing speed, a flex I used to have, is a dead skill now. I could type up to 120 words per minute. Doesn't really matter anymore. Talking speed, or as I'm calling it, voicing speed, is what matters moving forward.

So hey. Give it a try. If you're good at English, and you can speak your thoughts out loud, this is the new forward thingy. Ramble into a mic. Let the AI take the wheel to your next output.

With or without my help – I wish you the best.

If you saw my last post, I even used Claude Code to build this website. But one thing that has always been on the edge of my attention is, hey, you need to build a brain. A digital twin. XYZ. There are so many terms for this online. The point is the same. Bring everything under one roof and use that to run your day-to-day.

And that's kind of what I've started doing.

I finally made the leap and figured out how to do a local setup of Obsidian with Claude Code and VS Code, which is my IDE of choice. Obsidian makes it easy to read MD files, but mostly I've been interacting with Claude Code inside VS Code.

To kick this off, I started bucketing the main things I do. My business, Biz of Dev. The community, The Wandering Pro. The publication, SK Nexus. And obviously, I do have a life, so some life stuff is in there too. Accounting. Health. Personal journals. Whatnot.

Don't worry. None of this is being committed online. Claude Code seems to keep everything offline. And there isn't that much sensitive info in there anyway. Nothing I'd worry about a server looking up. Maybe a person looking it up might be an issue.

So yeah. I finally built a brain. And I finally got access to a Max plan, which is basically what enabled all of this.

Before this I was on the $20 plan, which already is very expensive for most people. But that one constantly kept running out of limit. One task at a time. Then switch to a new chat. Then a new chat. Then another new chat. The context window would keep running out. And as you can see, I do a lot of stuff. Having a chat that just keeps going is a blessing. It's what made the brain finally work.

Now, how is this useful? What does having a brain enable?

Quick gist. I work across many things. I maintain a consultancy-style job. I'm running a business where we have a couple of clients. I'm working with a couple of partners. There's so much context going on in my day-to-day that having something I can fall back on to ask questions and brainstorm with is genuinely important.

What I've been doing over the last two to three years is using the projects feature in various LLM tools. ChatGPT had projects. Perplexity has spaces. Gemini had Notebook LM. Then I started using Claude's projects too.

The problem with all of that. I had to switch between four tools. Four times I had to set everything up from scratch. Memory. Instructions. Context files. Project files. The whole effort, every time, from scratch.

That effort, I think, is basically intentional by design. A non-technical user gets stuck in that ecosystem and thinks ten times before moving away from it.

But given my life and how I operate with tech, I like to live outside the ecosystem. As agnostic as possible. I use a Windows computer, but I also use a Mac. I have an iPhone, but I also have an Android. I use mostly web-based software so things stay cross-compatible. So down the road, if I'm switching to Linux, wink wink, might happen, I don't really lose much.

That same philosophy, applied to LLM project management, is effectively setting up your brain. I now have a local folder with local stuff. Local context files. Local memory instructions. So if Claude suddenly wakes up one day and goes, F the world, the Max plan is now a thousand dollars, and everything runs away, I can switch the provider. That's it. I still have my brain functioning. No more migrations. Never again.

This was kind of a tech debt of its own kind. But now I'm slowly moving everything to local.

The takeaway. It's kind of funny. For years we were locked into ecosystems and platforms and proprietary software because the features they had were genuinely useful. But if you get out of your comfort zone a bit and start learning to use Claude Code, you can basically have all of that locally. Serving you. Customized to you. And you don't have to worry that much, as long as AI is a thing. I guess.

Even if AI isn't a thing forever, all of this is still just traditional code and files and MD files. You can plug it into some new tool down the road if you really want to. I don't see AI going away anytime soon, so I don't think there will be a need for that.

But ironically, the same tool that's killing farmland, burning servers, and racking up energy costs is also the tool that's bringing back the importance of having everything under your own ownership. Local. Away from SaaS software and other proprietary cloud storage. Having stuff locally is a big thing again.

This brain exercise was a really good one to finally undertake. Maybe next up, I'll host my own LLM, if I can ever afford the hardware.

If you've been on the edge of this and you're reading this, try it. You'll appreciate it. The shackles break free from the chain of SaaS software. You get to do whatever you want with your preferred AI provider. For me, right now, that's Claude Code. But it could be anything. Just plug and play.

With or without my help – I wish you the best.

Important caveat. It isn't the first thing I've vibe-coded. I've been using Claude Code for somewhere around seven months. Before that, plenty of AI in my workflow already. Research. Product discovery. Market scans. The kind of upstream work where AI was making me faster long before "agentic" became a marketing word.

But specifically Claude Code, on the keyboard, in a real codebase, is its own chapter.

It was the first AI tool that gave me a reason to open VS Code. Sounds small. It wasn't. I'd avoided it for years, because every time I tried I'd hit the syntax wall and back off to whatever chat tab was already open. Claude Code reversed the pull. The IDE became the place to think out loud, because the thinking partner lived inside it.

It was also the first AI tool that gave me a reason to learn GitHub properly. I'd been bouncing off GitHub for a decade. Knew what a repo was, never really used one. Inside seven months: repos, branches, push, pull, commits, merge conflicts, pull requests, the whole stack of conventions you absorb by doing. GitHub Projects has quietly become my go-to project management tool for anything complex.

That's not a feature of Claude Code. It's what happens when an agent makes the parts you don't know less scary.

Somewhere in this stretch I started calling myself a wannabe imposter dev. Not a developer. Definitely not. But not the dev-shy PM I used to be either.

Here's the part I'm proud of and slightly embarrassed by at the same time. I'm the kind of person who lives on execution. I don't read tech books cover to cover. I don't grind tutorials. I don't have the patience for "now let's do exercise 4.2." I learn by trying, breaking, asking, retrying. And for the first time in my career, an AI tool gave me a safe-enough sandbox to do that on real code.

Caveat on the word "safe." It wasn't actually safe until friends and mentors walked me through the basics. What to gitignore. What to never commit. What an API key looks like. What to do when you accidentally push one anyway. That took a couple of conversations and a few embarrassing moments. Worth it.

This personal website is the small, public token of all that. The rest of the sandbox, projects and prototypes and internal experiments, I can't talk about. Most of it isn't mine to share. Some of it isn't built to last. Some of it isn't built to be seen at all.

But this is the first thing I've taken from "vibe-coded prototype" to "live, polished, deployed, with my name on it, with a domain pointing at it, with security headers I can actually defend."

I've vibe-coded plenty of prototypes. Mock landing pages, scratch modules, one-off concepts to test an idea. Throwaway work, hosted on Vercel as a Claude Code artifact, no expectation of permanence.

A personal site is different. It has to actually stand up. It has to not leak a secret or carry an obvious XSS. It has to look like something I'd want to send a stranger to.

For the longest time my personal site was a WordPress install. Before that, hand-rolled HTML on whatever cheap host I had access to. Before that, a Substack I half-abandoned every time I remembered the personal site existed. Each version had its own problem. WordPress wanted updates and plugins and the occasional security panic. Each one died slowly because none of them were the right shape.

This time I told the agent: build me a static site, no CMS, no plugins, with the writing folded into the codebase so I can extend it by adding files. A folder is the database. Vercel is the deploy. The hard part was figuring out what I actually wanted first. Which is the work I run on every client engagement. Just this time, the client was me.

If you're a developer reading this, none of the above is a big deal. You ship production sites all the time. You can read what Vercel's serving and recite the CSP header from memory. Bear with me.

For someone who works across so many disciplines, owning the full output of a project, from product through to a live, polished, deployed thing, is what's actually new.

The hard version isn't the code. It's everything you have to not get wrong before something deserves to be live. Security headers. Sensible CSP. Real OG image. Robots and sitemap. Redirects that don't accidentally break the favicon. The dull little things that separate a sketch from a site.

The agent doesn't do that for free. You have to ask. Specifically. Repeatedly. Sometimes with screenshots. Sometimes by reading the security report and pointing at the failing check. The discovery is real, the spec is real, the back-and-forth is real. The agent just removes the syntax tax.

Seven months ago there was a clean line between "vibe coding" and "real coding." Vibe coding was the joke that wasn't quite a joke. Prototyping, demos, things you wouldn't show a developer with a straight face.

Seven months in, the line is blurry. A lot of the developers I know are using Claude Code daily, on production code, in real workflows. They don't call it vibe coding, because to them it isn't. It's just coding now.

So am I a vibe coder? I don't know. Vibe Product Manager? Maybe. The label probably doesn't matter. The shift does.

Here's the takeaway I didn't expect. This is the most technical I've ever felt in my career as a PM. After more years of being a PM than I want to count. I can hold real conversations with developers now. I understand how the parts fit. I understand how repos are structured, how databases get queried, how front-ends call back-ends, how deploys actually work. None of that knowledge would have arrived through articles. None of it would have arrived through books. I'd have bounced off both.

It arrived because I had a tool that let me execute on the things I was curious about, instead of just reading about them. The execution taught the theory in reverse. That isn't how I expected this to go.

A few notes from the trip:

The thinking is still the job. When I had a clear sense of what I wanted, things moved fast. When I didn't, we both wandered. The work isn't writing code. The work is knowing what you'd write if you could.

Spec-driven beats prompt-driven. "Make me a website" gets you a generic site. "Build me a static personal hub with a journal at /the-rift, file-based entries, no platform lock-in, and a CSP that doesn't break embeds" gets you something you can actually live with.

Production has tax. Prototyping doesn't. The last 20% is the part most agentic demos quietly skip. It's also where most of the learning lives.

I still don't claim to be a developer. I'm not, and I won't pretend otherwise. But my respect for software development is higher than it's ever been. The work is harder than it looks. The discipline is real. The cost of getting things slightly wrong is high, and developers are the people who quietly absorb that cost so the rest of us don't notice.

With or without my help – I wish you the best.

This is the place where that happens.

A quick stocktake on what I'm doing in 2026, since some of you have asked.

Biz of Dev — the discovery-led product studio. Spent 2025 quietly refining what we do. 2026 is about building the portfolio side of it. There are conversations underway, partnerships being formed. The bet is still the same: discovery before development. Most projects I see fail because someone skipped the cheap step (finding out whether the thing is worth building) in order to rush the expensive one (building it). Biz of Dev is the team that won't let you skip.

SK NEXUS — what started as "tech, but explained for the average Bashir of Pakistan" has slowly become "tech, but explained for anyone, anywhere." The framing changed when I realized the same people I was trying to reach in Lahore were the same ones in Lagos, in Manila, in São Paulo. Context is the new king. Most publications still write for the same Western reader the early internet trained them to write for. There's a gap there I'm still excited to keep filling.

The Wandering Pro — the community. 2025 was the year I grew it. 2026 is the year I support the active people inside it. We have folks who started by joining for a free guide and ended up shipping their first SaaS, or landing their first remote job, or finding their first paying client. Helping those people get a slightly less brutal version of the journey I had is the thing that still keeps me up some nights, in a good way.

Consulting through ProParadigm. Still doing this. The lights don't pay for themselves. Honestly, also still my favorite venue for working with founders directly: you talk to someone, you understand their problem, you help them solve it, you both move on. No org politics, no bloated process, no committee deciding what color the discovery deck should be.

The Rift — this thing. Folded into saqibtahir.com this time around. Not its own platform with its own subscribe button and its own onboarding flow. Just a page. A page I add to when I have something to say that doesn't belong anywhere else.

The thing I keep coming back to: the work I do scatters into too many places. The studio for clients. The publication for tech explainers. The community for builders. The consulting for direct help. Each has its own job, each its own voice. None of them want my random Tuesday thoughts on parenting an idea, or noticing what a friend's launch did right, or untangling whatever I'm currently confused about.

So this gets to be that place. The Rift, again. The mismatched bin under everything else.

Plans for the Rift in 2026, while we're at it: less newsletter, more journal. Less framework, more observation. Less "here's how to do X," more "here's what I'm noticing about Y today."

Welcome back.

With or without my help – I wish you the best.

You google "GTM strategy" and drown in advice made for Series B companies with full marketing teams and $500,000 launch budgets.

Welcome to reality.

I've lived in the trenches launching B2B products for both scrappy startups and funded scale-ups. And I can tell you one thing for free: spending your way out of early-stage uncertainty never works.

What works is brutal prioritization. Ruthless focus on what moves the needle. Relentless action on the things that compound.

This is what I call the Poor Man's GTM. (Branding credits to Scott :D)

A field-tested roadmap to get your B2B idea in front of real customers, with minimal cash and maximum learning.

I've had the privilege of working with dozens of startups at every stage of the product lifecycle. I've walked both paths, helping teams build their first prototypes and MVPs (MVP, like a skateboard), and later stepping in to drive the go-to-market when the product was finally ready to face the real world. Defining epics, user flows, tech architecture. Designing value propositions, shaping landing pages, running customer interviews, leading the first content plays. I've worn every hat from product builder to GTM executor.

That combination is what inspired this framework. It's built from experience, not theory. Every recommendation comes from real application with founders, product teams, and early customers. My job has always been to reduce noise, focus on what actually drives outcomes, and get startups across that painful zero-to-one chasm.

If you're there now, I get it. I've been there too. Let's get you through it.

Here's the mindset. You are exchanging money for time. Cash is scarce, so your edge comes from fast learning cycles, saying no to 90% of distractions, accepting imperfect early versions, and maximizing conversations with users over passive metrics.

Your motto: stay ugly, stay fast.

Three caveats before the tactical part, because I don't want you walking away with the wrong idea.

One, on ROI. This emphasizes time and effort over cash. It's high-leverage, but don't mistake it for high-speed. You'll get conversations, direction, and a sense of what's real. Not viral growth from day 1. Paid media and agency polish can help you scale faster, sure. But without a foundation, they only help you burn faster. The Poor Man's GTM is not anti-money. It's pro-sequence. Spend later, after you've proven your positioning.

Two, on personal branding. If you have an audience, use it. Ruthlessly. A founder with a strong personal brand can skip 70% of this list by showing up online consistently and talking straight to their people. In that case, jump to the content part, skip the paid tools and the cold outreach, and just build in public, demo your stuff, and offer value. For everyone else, this exists so you can build your own gravity from scratch.

Three, this is a starting point, not the end-all. It's not a VC-grade GTM plan. It's your survival kit. Something to get you from idea to traction without wondering where to even start. Once it gives you signals, layer on brand, performance marketing, and sales. But don't let the absence of perfect materials keep you from starting.

The common thread across all three? Don't overthink. Don't wait for perfect. Don't assume traction is guaranteed. Your only job is to build real feedback loops and momentum as fast and as cheaply as possible.

So here's where to actually spend your time, not your money.

Figure out your value prop first. You can't market what you can't explain. Get your co-founders or product team in a room for two hours, grab a free Value Proposition Canvas, and work through it. Who do you help, what problem do you solve, how does the solution create value. Identify your primary and secondary segments. List their jobs-to-be-done, their pains, their desired gains. Match your features to the pains they kill and the gains they create. Then distill all of it into a single value proposition statement. This is the foundation for every pitch and every touchpoint after.

Then the positioning and copy for your landing page. Your landing page is your pitch deck. It has to answer three things: what is this, is it for me, why should I care. Start from your value prop. Write a headline that names your customer's biggest pain. Follow with a subheadline that explains your solution. List 3 to 5 key benefits. Add one strong call-to-action. Then test the draft with 3 to 5 non-customers and ask the only question that matters: "Would you sign up?" (I went deeper on the landing page itself here, Storefront.)

Copy done? Now actually design and build the page. You learn faster by launching a bad landing page than by polishing one forever. Sketch the structure in Figma, Miro, or on paper. Hero, then value prop, then CTA, then signup form. One clear call-to-action, no more. Build it with something simple like Carrd, Framer, or Webflow. Wire the form to a Google Sheet or an email list. Launch it to your network and your communities. Then watch the signups and let the feedback rewrite your messaging.

SWOT and competitor analysis next, and yes, do it. Understanding your market keeps you out of founder delusion and helps you spot your wedge. Name your top 3 to 5 direct and indirect competitors. Run a simple SWOT, your strengths and weaknesses, the market's opportunities and threats. Do it for the competitors too. The gaps between you and them are where your positioning lives. It saves you from building "me-too" features.

Then quick-and-dirty market research. You don't need expensive reports. You need actionable insight, fast. List 20 to 30 potential customers who fit your ideal user. Reach out over email, LinkedIn, or mutual connections. Set up 10 to 15 short discovery calls. Ask open questions about their workflows, their pains, their current tools. Write down the recurring themes. Talking to customers directly validates your assumptions and uncovers unmet needs for free, which is the cheapest risk reduction there is. (More on market research, Market research, misunderstood.)

DIY demo videos for each segment come next. Customers want to see, not be told. Pick your core segments, name the 2 to 3 problems each one has, and record a screen-share walkthrough with Loom or Zoom. Keep it 2 to 5 minutes: problem, workflow, outcome. End with a call-to-action. One good demo replaces hundreds of manual sales calls.

Set up a feedback loop. Unfiltered feedback early prevents you from building the wrong product. A Google Form, Typeform, or Notion board is enough. Categorize it: bugs, feature requests, general suggestions. Block a recurring weekly or bi-weekly slot to review it, spot the trends, and ship the fixes that keep showing up. Then tell users what changed.

Run a real customer interview process. Nothing replaces hearing a real customer explain their pain in their own words. Build a list across your segments, reach out for short calls, and prepare a lightweight script of 8 to 10 open questions. Focus on problems, workflows, frustrations. Listen 80% of the time. Speak only to guide. Do at least 10 before you read patterns into any of it. At nearly zero cost, you walk away with the exact language your customers use, and that language belongs in your product and your copy.

Build a minimum viable content strategy. Consistent content builds trust and positions you as someone worth listening to. Define your ICP and write to their challenges. Post 2 to 3 short, useful pieces on LinkedIn a week, and one deeper article or newsletter a month. Help, don't perform. Repurpose: a post becomes an article, an article becomes a carousel. And reply to comments and messages like a human, because that's where the relationships actually start.

Finally, minimal tracking and analytics. Early data tells you what's working before you've spent a cent proving it. Put Google Analytics on the site for basic traffic and behavior. Add Hotjar or Microsoft Clarity for heatmaps and click tracking. Use UTM parameters on every marketing link so you know which channel drove the signup. Track only the core numbers. Stay on free tiers until traction earns the upgrade.

Now the other half, the part nobody enjoys. What you should NOT do yet.

Fancy brand guidelines (2 colors and 1 font is plenty). Enterprise CRMs (Google Sheets or Notion will do). Paid ads (not until you have organic traction). Perfect onboarding flows (iterate from real user pain instead). Complex pitch decks and sales kits. The Poor Man's GTM is raw, functional, lean. Looking impressive is not the same as being effective.

Here's why this works. Most startups don't fail because they built the wrong product. They fail because they ran out of time and money before they proved anyone wanted it. This playbook isn't for impressing VCs or winning design awards. It's for learning faster than your cash burn rate. Every week you delay testing your value proposition is a week closer to dying.

Build conversations. Build learning. Build actual demand. Then scale. Not before.

A few things that punch above their weight. Lean on social proof early, even a handful of pilot quotes signals momentum on a landing page or a post. Network with micro-influencers in your niche, but ask for advice and feedback, not endorsements, and the advocacy follows on its own. Spend your time in the channels where your audience already hangs out, the LinkedIn threads, the niche forums, the Slack and Discord rooms, and participate instead of pitching. Launch a simple "invite a friend" reward, because word-of-mouth loops kickstart growth faster than ads. And don't sleep on cold outreach. Cold calls, DMs, and well-written cold emails are still the most reliable ROI channel in early B2B sales.

Most B2B founders don't fail from bad products. They fail from slow feedback, burned cash, and no clear signal of what's working. The Poor Man's GTM isn't glamorous. But it's what actually moves you forward, one email, one landing page, one user conversation at a time.

This isn't a blueprint. It's a bet. And every bet you test is one step closer to traction.

With or without my help – I wish you the best.

I'll leave "100% GUARANTEED RESULTS WITH THIS ONE SIMPLE HACK" to the CRO crowd. I want to talk about the fundamentals of a landing page that just works.

In the old days you pitched investors in a boardroom. Today your landing page is the pitch. To customers, partners, press, and the investors who will stalk your site before they reply to your email.

If you can't explain what your product does, who it's for, and why it matters, right there on the page, you're not ready to build, raise, or sell. Period.

Most early-stage founders treat the landing page like an afterthought. It becomes a dumping ground. Buzzwords, scattered features, "let's just get something up for now." 20 headings, 30 sections, every animation the designer could find. And the visitors run.

I'm a product person. I believe in optimizing on data and feedback. But you can't optimize what isn't set up right to begin with. A 90% bounce rate tells you nothing useful. Get the fundamentals in place, then improve over time.

I've worked on landing pages across 100+ web projects, on Upwork and at Biz of Dev, and for an early-stage startup the page carries a lot. It has to explain what the product does in plain English, make the problem clear and who you solve it for, show the features that actually matter, build trust with proof or credentials, show people how to start, deliver the offer with zero confusion, and look like your brand instead of a Canva design.

That last one is the whole problem. Most businesses miss the fundamentals and cram in everything. Here's the order that works.

Problem. What real-world issue are you solving?
Solution. How exactly are you solving it?
Value prop. Why does your approach matter?
Trust. What makes you credible?
Design. Is it easy to follow and use?

Not the end-all guide to every landing page. Just the one that performs best for an early-stage business.

This next part is where you have to be honest with yourself.

No, your product doesn't solve every problem. No, your business doesn't do everything. No, your offer isn't best for everyone. No, your solution isn't the most groundbreaking thing ever built.

Here's what can be true instead. Your product solves the right problems for the right users. Your business does what matters most in your niche. Your offer gives the highest value against your competitors. Your solution is driven by your mission, not by fad features.

You look at post-product-market-fit startups and think you need to match them. Every feature, everything all at once. You don't.

If you're reading this sure that none of it applies to your product, maybe you need a rediscovery of your idea. Or maybe I just don't have the monopoly on being right.

If you're B2B, map the operational and efficiency problems. Speak to business needs from your research, not to everyone. You're talking to a decision maker, so talk ROI, workflows, and how you slot into what they already run. Skip the cheesy empathy.

If you're B2C, talk to the end user. Benefits, not specs. Plain language, no invented lingo. The page should scream "I know exactly what this does for you." Keep headings short, explanations shorter, and lean on visuals.

For both, run your copy through a tool like Hemingway and aim for a grade 7 reading level. And the real test: can you say your problem and solution out loud, from memory? If you can't picture your own landing page, your users won't remember a word of it.

Good problem and solution statements get people scrolling. Then they hit the question, what's in it for me?

That's the value prop. In almost every business you win one of two ways. More value for the same commitment, or the same value for a lower commitment. Decide which one you are and the messaging gets a lot easier.

Most people botch this section. They spam features, or benefits, or every shiny thing they can find. Stick to 3 benefits, max. 3 is easy to remember. And don't just state the outcome, show how you get them there, with a visual.

The hard thinking is done. Now you lay it out. One thing I tell everyone I work with: don't reinvent the wheel. Websites have been around a long time. The structure is a solved problem.

1. Hero with one CTA, above the fold
2. Social proof (companies, accreditations, anything that earns a second)
3. Problem statements
4. Solution statements
5. How it works (only if your product is hard to adopt)
6. Value prop, with visuals
7. Testimonials. Real names, real faces, ideally from a third-party tool.
8. A re-offer before they leave

Have these at the least. Messaging and branding change by product, the skeleton mostly doesn't. Best part, you can wireframe the whole thing yourself in something like Miro and speed-run to a final design.

Once it's built, handle the boring stuff. The number of startups that skip this is ridiculous, and you don't need to be an SEO expert to get it right. Make it responsive, because over half your traffic is on phones. Click through every CTA before launch. One H1 per page, and scan it with a tool. A meta description of sensible length. Connect Google Search Console and confirm it's indexing. Force HTTPS, no bare http. Optimize the images for speed. Wire up analytics. Test the signup email actually lands, before launch and after. Sticky header on desktop, minimized on mobile, and for single-pagers use anchor links to move between sections.

A landing page carries a lot. Make an impact, earn trust, understand the user, get them to act. I don't believe in perfect. I believe in iteration.

You won't get it right the first time. That's fine. Ship something solid, gather real data, improve. Get the fundamentals right and you have a foundation worth building on, instead of starting over every time.

Your landing page isn't about showing off. It's about making it dead simple for the right people to say yes.

With or without my help – I wish you the best.

Marketplaces are cool.

Established platforms, with apps that improve the functionality the big guys are too slow to build natively. Living, breathing platforms that generate businesses and livelihoods all around. (Let's stay positive for this one. I'll cover Sherlocking some other time, maybe.)

Every product that goes full blast ends up with one.

Shopify has its app marketplace. WordPress has its plugin world. Discord has its integrations. Monday.com has its apps. The list goes on.

There's a reason iOS and Android are dominant, and it isn't just the OS. It's the breadth of apps people demand on their phones. R.I.P. Lumia and BB OS (arguably better, or is that just nostalgia?).

Same story in B2B. Large platforms can't keep up with the demands of their users, so the only way to scale is to open up to integrations, then eventually run a full marketplace.

I've been working in this marketplace world for the last 8 months, and I've learned a lot. Today I want to go over one problem I see every marketplace app run into. Copycats.

So why are copycats a uniquely painful problem here?

Unlike standalone products with a much larger audience, marketplace apps are purpose-built by definition. People need a specific solution or integration. You build an MVP for that need. It takes off, and now you have a successful product. Most indie marketplace apps start exactly like this.

But here's the core issue. Marketplace products are inherently easy to copy. You identified a gap in a platform's functionality and you solved it. Great. But you also published the blueprint for everyone watching.

So the next person who does it can do it faster, cheaper, and better. Effectively, all they have to do is copy your idea and sell it for half the price.

(This happens off the marketplace too. It's why apps like Clubhouse make PMs ask "is that a product, or just a feature?" Most single-feature apps get quietly integrated by the big players the moment they get popular.)

When your product lives inside a marketplace, you will face copycats. That creates constant pressure to evolve and stand out. Otherwise you get stuck in a race to the bottom on price.

So at the end of the day, marketplace or not, the goal is a sustainable business. Any advantage you have today vanishes the second the gap closes. Your job is to take a lead, and then keep the lead.

So how do you actually respond to copycat competition?

I don't want to go full 7 Powers of Hamilton here. I think that's better saved for a more mature product. So my version, for you, for now, is an abridged one. Let's call it the 3.14 Powers of Hamilton.

Three priorities, IF you already have a lead with your product. I'm using levels to highlight the urgency of each one.

Level 1 is your immediate response, in days or weeks. Level 2 is medium-term differentiation through pricing and positioning. Level 3 is the long-term strategy that changes how customers see you. Fighting marketplace competition takes a layered approach. Quick, tactical moves up front, real strategy behind them.

Level 1: support and social proof.

When a new competitor shows up with similar features at a lower price, here's the thing they'll lack. Customer support.

This is your quickest win. Competitors can copy features. They can't instantly replicate your experience or your customer relationships. Business users, especially on Monday.com or Shopify, live and die by reliable support. Their projects and stores depend on it.

A few things to implement ASAP.

Cut response times dramatically. Find the issues that take longest to resolve, work the common themes, and prioritize the turnaround on those. Build user-feedback-based roadmaps. Show people how you're fixing things. If something's going to take a while, tell them, and tell them you're on it. Transparency buys you a lot of goodwill. And expand your support team. Your first scalability hire outside the dev team should be support. You, the founder, should not be the single source of truth for every support concern.

There's a great case study I can't find the link to anymore, about acquisition firms that specifically target rising products with weak support. They buy them, fix the support, and flip them for sometimes up to 5x the original value.

For a small product, exceptional support is the moat you can almost always rely on. Especially on a marketplace, where someone's business runs on you. It also builds loyalty toward whatever you build next, and you will be building next if you want to keep your lead.

So you tell me, "Saqib, our support is already excellent, we can't do better there."

Then are you doing enough with it? Enter social proof. The second thing that makes you hard to copy. They can copy your feature. They can't copy your support, or your reviews, or your case studies.

For marketplace apps, support and social proof are the two biggest factors. But whatever you're building, there are always 2 or 3 things with the highest ROI when you measure them against being anti-copycat.

Level 2: pricing and value differentiation.

No matter how good your product is, once there's a copycat, pricing ends up on the table. And it's the trap that drags you to the bottom if you keep thinking in terms of X dollars for Y inputs.

Fun fact, as I write this, OpenAI has a version of this exact problem. Their token pricing makes less and less sense as other providers find cheaper ways to do the same thing, and now they're in the rut of having to price around value too.

You can refactor your pricing to stay ahead once, or twice, or three times. Keep that up and you're not competing anymore, you're catching up.

So use this as a reason to rethink it. First, communicate your pricing better. You're the bigger player. More users, more costs, more maturity. The customer doesn't know that yet. Bake it into your pricing descriptors. Support turnaround. 24/7 availability. A custom onboarding team. Better trials. Things a new competitor can't, or won't, match.

Then start experimenting with value-based pricing. Move past simple feature counts. "X dollars for Y features" commoditizes you. Consumers hate value-based pricing, sure, but business users will accept it, because your value is your maturity. If a business is going to rely on you, they need to know you'll still be here. Let that fact comfort you.

And avoid pricing that makes direct comparisons easy. Per-unit pricing works when you're new. You're not new anymore, and you do a lot of things that can't be quantified. If your pricing is still X things for Y dollars, you're shooting yourself in the foot.

I don't want the takeaway to be "charge more because you deserve more." Charge for the value you provide, which goes well beyond the features.

What often works is a tier where you make no money on purpose. You want people inside the platform, seeing the value, then moving up to the pricier option. Offer more than basic tiers. A loss-leader to compete on price. A premium halo package with high-value features at higher margins. Diversified pricing keeps customers from writing you off as "too expensive," and it gives you room to upsell. Another thing that makes you harder to copy.

Level 3: long-term positioning.

In the long run, even inside a marketplace, you have to think like a standalone product. Competition keeps coming, ideas keep popping up. But before any of that, work on your product strategy.

Start by building feedback loops with your best customers. Dedicate 10 to 20 hours a month to talking to them. Validate adjacent features that compound on your core. These conversations surface high-value opportunities, deepen your key relationships, and give you early validation before you spend real resources. Your lead is your current customers. Don't waste that.

Then reposition. Stop being "the app that does X." Be "the champion for cross-functional work," or whatever broader theme fits. Get specific and detailed about who your app is for. It's far better to be loved by a defined group than liked by everyone. That's the thing that makes you hardest to copy.

If you want to think about strategy in the broader sense, I wrote about that here.

So what's next for your marketplace app?

You fixed your support, built your social proof, sorted your pricing, and you've got a real strategy to grow. Now what?

Now it's time to get out of the marketplace.

As my night gig, I help freelancers and professionals with their careers at SK NEXUS. The common advice is to start on a platform, get successful, then go direct for new clients. This is just the product version of that.

Your app started as a single feature integration. It grew as your customers grew. You added more over time. Now you've got a suite you can take outside the marketplace.

It's time to graduate.

With or without my help – I wish you the best.

Simply put, it's a set of tasks you run to understand the vision behind the product you're about to build. No matter who you are or what you're building, discovery is where you explore the uncertainty behind your idea, identify the problems you can actually solve, figure out the right solutions for your audience, look hard at the market, get honest about the vision and goals driving the business, and document all of it so you can get to execution faster.

There are two ways to take discovery. Foundational and continuous.

Foundational is the first discovery you do before building your product. Continuous is the practice of discovering your existing product over and over to improve it. Product companies understand the second one well. For today, let's stay on the foundations.

The most common question founders ask me is some version of: why the heck would I need a discovery session?

Here's the basic explanation. Product management lives at the fronts of Ideation, Planning, Design, Development, and Launch. Each of those has one critical thing the product person usually leads. For Ideation it's Product Discovery. For Planning it's prioritization and documentation. For Design it's UI/UX mapping of features. For Development it's the build process and project management. For Launch and beyond it's go-to-market and product strategy.

Discovery is the front door. Get it wrong and everything downstream inherits the mistake.

The work splits into two stages. Exploration of the problem, and validation of the solution. Depending on your product you'll lean on one more than the other, but the validation never happens until I have a complete picture of the exploration. You can't validate a solution to a problem you haven't actually understood yet.

So how do you run one properly.

You start with a kickoff. The point of that first meeting is to ask the dumb-simple questions and see if the answers exist yet. Can you explain the business vision and goals in a summary? Who are the key categories of users? Who are your main competitors? What does your team setup look like? What are the pain points you're trying to solve, and do you have them in writing anywhere?

You'd be surprised how often "in writing anywhere" is where the room goes quiet.

After the kickoff I write up a detailed summary, build out a full discovery questionnaire, gather every scrap of existing documentation, and plan 2 to 4 workshops. Then the real work starts.

The workshops break into four phases.

The first is business understanding. We go over the high-level vision, the long-term and short-term goals in your own words, the risks and challenges and the metrics success will actually be measured against. Then your product's value and what makes it unique, the differentiating features, the core values the business wants to stand behind. And finally the problem and solution statements, written down, matched to features.

The second is product-market fit foundations. Eventually PMF is the goal for every product, and getting off on the right foot with the market is most of the battle.

With the right team, anything can be built. With the right product, anything can be sold. And with the right market, anything is successful.

Here we list the direct competitors and the indirect ones, and do the one-thing check. One thing you definitely want to adopt. One thing you never want to adopt. One thing you want to do differently. Then a SWOT pass and an elevator pitch, built off the For, Who, Our, Provides, Unlike structure. Then positioning and differentiation, because, quick tidbit, those two are not the same thing. Product positioning is about how consumers perceive your product. Market differentiation is the strategy you use to show why your features beat the competition's. Semantics, yes. But the difference earns its keep.

The third phase is user segmentation and experience mapping. A good user experience can make or break a product. So we segment the user groups, define their demography, habits, tech savviness, and any feedback you already have. We list every pain point per group and every frustration with the tools they use today. Then we map the journeys, from discovering your product to actually learning to use it, and tie those journeys back to the pain points.

Here's a fun question. What comes first, having users or having a product? Chicken and egg, really. Mapping out the users for a product that doesn't exist yet feels a lot like forecasting Tesla stock. Shoots up? Dives down? Your guess is as good as mine.

Fail jokes aside, it isn't pure guesswork. We have the technology (says in Patrick's voice) to figure out, to a pretty good extent, who you should be building for. Tested frameworks, data, tools, experience. The customer is always right in matters of taste, so you'd better serve what has an appetite.

The fourth phase is execution. All planning with no action is just a failure of execution. So we cover the tech stack, the resources, the team you'll need for the next 90 days of your product. We map features by priority, must have, should have, could have, weigh the high-priority ones against the high-risk ones, and draft the MVP.

And here's the thing one size does not fit. The execution plan is always tailored to the resources, the budget, the time you actually have. Anyone selling you a fixed recipe is selling you someone else's product.

Everything funnels into one deliverable. A detailed findings document. A design plan, a roadmap, a SRS, a PRD, a SOW, it has many names, but the goal is simple. You should know what to do next.

This document becomes your single source of truth for future reference.

There's a line from Marty Cagan, founder at SVPG, I keep coming back to:

"We have always had, and likely always will have, two essential problems in software: we need to figure out the right product, and then we have to build the product right."

The first half is discovery. The second is execution. Most teams are excellent at the second and terrible at the first.

Which brings me to the pushback I hear most. "I already have an MVP ready to ship. Why would I need discovery now?"

No matter what stage you're at, discovery can still apply. I've run it on products from scratch, on refreshes, on V2s, the list goes on. Discovery is the journey that gets you to a destination, not a box you tick once at the start.

If you're a founder reading this, tell me you've never second-guessed what you're doing. You feel like someone should be validating your concerns. You feel aimless with nowhere to turn. Those are the exact pain points a discovery is meant to solve.

So should you run one? Base it on what you genuinely need. Only do the phases that are necessary, skip whatever's already settled. Quick self-assessment: do you clearly understand at least 3 core problems you're solving? Do you have detailed solutions for each? Do you know who you're solving them for, and what the market already meets? Do you have evidence your USP is not just unique but useful? Do you know the resources execution will take, and how you'll measure success?

If every answer is a confident yes, discovery isn't for you right now. But if you're being honest and you have doubts about even one of them, you need one. Now or later.

Market research and discovery go hand in hand. If you want the fuller picture, read Market research, misunderstood next.

With that, good luck finding your fit in the market.

With or without my help – I wish you the best.

Consultancy taught me that being the right partner to the right person can 10x anything inside a year. My way of working was always about filling the gaps. See where the other person falls short, and match the gap.

So even though I found a lot of success being a partner to many, when it came to finding a partner for my own gig, I failed.

This one is about the lessons. From being a partner to many, to looking for a partner for my own business. May you learn something from someone who has played both sides.

The founders that always pulled me in had three things going.

Bootstrap mentality. Solving problems with the resources at hand. As an ex-engineer, working inside constraints is my playground, and a startup is the same thing. Founders who work within limits often go beyond them.

Openness to ideas. When you're in the business of solving problems, you need to stay open to alternatives. New ways to cure old diseases. Founders open to new ideas are the ones who create new possibilities.

High motivation, for the right reasons. Founders building something they're actually proud of are rare. Most will run with an idea "just because" and assume that's enough to change something. It isn't. But every now and then you meet the exceptional ones, the people who'll give years to what they believe in. That's the sweet spot.

If your pitch to me was "this will raise millions in funding" or "if we only capture 1% of the market," I'd stop you right there and send you back to the drawing board.

Here's the analogy I keep making to founders. Just because you love cars, and you drive one every day, and you know what goes inside one, does not mean you can go and build one. Software is arguably easier than building a car, and the same logic still holds. A lot of founders have the right heart and want to build the right thing, but their approach is usually wrong. I've watched them burn money on expensive outsource teams, on tools they never need, on consultants working on things that don't matter yet. The right partner is a shortcut to the right resources. Team, tools, or hacks, if you bring in someone who has built from scratch before, your work gets 10x easier.

For a long time I was the guy who showed others the way.

Then I went looking for partners for my own thing. Five-plus burnt partnerships later, here's what I learned.

1. Match the missing frequency.

My whole thing has always been execution first, talk later. I'm a strong believer that ideas are cheap, and the only thing that makes one stand out is execution and proof of it.

I've never left my home base for work. Pakistan, the whole time. So I figured the people who'd made it outside maybe had something I was missing. When I went looking for partners, I found plenty of interest, mostly from folks stuck in jobs trying to break into business. The deal was simple: I help you execute, you help me get out there. On paper, perfect.

In reality it never happened. Time and time again, the people who talked big never walked an inch.

So if I'm the guy who lives on execution, I need someone who matches my pace. Now I only partner with someone willing to work on execution, not just talk. They get an assigned workload and they're expected to deliver it. I ask for proof of work, not promises of it.

2. Check at least two of three boxes.

If you're self-aware enough, you know what you're good at, and more importantly what you're bad at. So when you look for a partner, aim for two of three: a skill you lack, time you can't give, money you don't have. If they're not covering at least two, it ends as a failed partnership. Time, money, and skill are what run a freshly started startup. You'll usually front it the first 6 months, but after that your partner should be filling the gaps, or at least complementing them.

My biggest mistake was thinking the skill I lacked was "networking." Always working online and remote, I never got into any good network or guru group. So I figured if I found someone with a strong network, I could use their skill to push my execution forward.

I was wrong. Network isn't a skill. Network is an investment.

A good network isn't followers on LinkedIn or subscribers on YouTube. It's knowing the people who exchange favors. And if you want favors owed to you, you start by owing them yourself. Once that clicked, I understood why none of it worked: when the time came to actually use a partner's network, they were as good as me, basically no follower count required.

Now I judge a network by impact, not vanity. I ask about the initiatives behind it, and I dig into who someone actually knows. As for me, I still lack the personal-branding and marketing skill, I lack the time to build extra sales channels, and I lack the money to invest in anything beyond the team I have. So whoever partners with me next had better check two of three.

3. Apply ruthless prioritization to the partnership itself.

Your strategy, your need to outcompete, that's what makes you successful in the long run. And sometimes you have to make sacrifices on the way.

Sunk cost is the biggest concern for anyone launching a startup. Especially when you've partnered with someone. Don't let the downward spiral run past 3 months. Don't partner on a "side thing" you both swear you'll do for the long run. One of you won't.

Ruthless prioritization isn't just for your dev work, it's for how you partner. If something isn't working, cut it as soon as possible. My biggest mistake was giving too many chances, letting things drag until they were far more painful to cut. Now anyone who approaches me for a partner role gets a time limit. No way around it. I need to see patterns of a successful future before I commit to one.

4. You "need" a technical cofounder if you're non-tech (and vice versa).

Y Combinator's cofounder matching is a nice start for anyone looking for their first match made in Silicon Valley heaven. But it pushes the 50/50 idea way too hard. Find your exact opposite half or you're doomed.

That's an extra-large lie.

You, as a good founder, must have some knowledge across every front, tech or not. Finding a technical cofounder does not mean you get to have 0 technical understanding. If anything you should aim for more, especially on the user side.

I've been a product manager at heart, and to this day I can't code. But I've worked with over a 100 developers, so I understand how apps and products get built. Do I still benefit from a technical cofounder? Yes. Will I be left to die without one? No.

That's the important bit. As a founder you need to be ready to be left alone at any stage. The help from a partner is real, but don't sink your trust in too early. Same goes if you're on the tech side. You need to understand business, ops, sales, and marketing to a level. Nobody waves a wand and fixes it all for you. That's not how this happens.

5. Don't find the right partner, build them up.

Over the past 2 years of looking for people to hire and partner with, my best results came when I nurtured the relationship before the ask. By far the best people I got to hire or partner with came from my community and the networking I'd been doing for years. Months of sharing knowledge, like this very piece, helping others grow, putting my ideas out where they could land.

I found people who worked with me in my community and knew how I work. And those people became the shoulders my ideas stand on. I'm still open to new partners, as long as the lessons above hold up against them. The best way to find the right people is to lead the right people into working with you. Show them how you work, inspire them, and great people love working on great things.

Simple as that.

When 2024 ended I posted this on LinkedIn:

I've been gaming under the tag "SoloKarry" for the past 15 years. And I'm fairly certain I took that mentality literally when it came to my life, work, and relationships. I've done everything in loneliness, for the most part, especially in career. I had people helping me, I had mentors, I had good friends, but at the end of the day it was me, my computer, and a screen. That reached its limit this year. Solo won't work anymore if what I want to achieve is scale. Scale requires people, and people require a tribe.

Not everyone needs a partner, and not everyone should have one. But you do need to know your limits. And to go beyond them, you need the right 10x'ers at your side.

With that, I leave you on your own search for the person who can fill that role.

With or without my help – I wish you the best.

Let's go over why you should care about market research as an early stage founder.

Work with enough startups and one thing gets clear fast. Most are being built on whim and pure intuition. There's a reason 90+% of startups fail to get off the ground. Makes you wonder why 🚀 is the universal symbol for a startup.

Most founders get that "one idea" they believe is the be all and end all. Then they keep building on it without any research or understanding of the market.

Don't get me wrong, I've seen the other side too. Where every decision and every direction is over validated, which has its own problems. There's a reason intuition matters as much as data when it comes to landing a product.

You've heard the phrase "you only have to be right once."

Here's my take. With the right research and effort, you can avoid being wrong a lot of times.

The best place to be is the middle. Lead with your intuition, then plan smart efforts into validating the key areas around your idea.

I've been on the frontlines for over a decade now, so I have a decent handle on what matters and what doesn't. Google "market research" and you'll find a hundred ways to run one. The problem is that most of them don't deal with what you actually need as a startup at an early stage.

My targeted approach is built to tackle 3 things:
→ Understanding your competition.
→ Understanding your market position.
→ Understanding the trends in the market.

Consultancy and advisory has a bad rep with transparency. Most providers hide the foundational stuff until the first check clears. I'd rather walk you through every step, so here's all you need to know.

As an early stage startup you only need a few areas locked in. Overcomplicating the process takes you two steps back with one step not going forward. Here's what to lock in as early as you can:

→ Competitor analysis for your direct, secondary, and indirect competitors.
→ A SWOT analysis for your position in the market.
→ Elevator pitches to sharpen your messaging.
→ Market trends and learnings to help you make decisions.

The end result is a full picture of where you stand. Market is by far the biggest reason behind failing early vs growing 10x. You can lean on this with every decision you make, right up until you're a scaleup.

The competition.

Can't tell you how many times I've heard "we have no competition."

You might be right. In most cases you'll be wrong, and surprised how wrong. When it comes to software, the democratization of how to build and distribute tech means anyone with the right skillset can go build an app. Most of what exists has been done before, or it's a transformation of an existing concept. Your idea might be unique. The execution of it doesn't have to be. They say "don't reinvent the wheel" for a reason.

If there's no exact match, you go for secondary, indirect, tertiary. The semantics go on. So what's the difference? Glad you asked.

Direct competitors offer the same product and service, in a similar market, at a similar price point.

Secondary competitors are close to direct, the difference being the market. Same product, but a different market or a different price point.

Indirect competitors flip it around. Same market as you, but a different product or price point. They have aspects you should aspire to as you commit to the research.

Once the list is ready, you rank them with a mix of qualitative and quantitative notes. It varies product to product, but generally you start by writing down 2 to 3 positives, 2 to 3 negatives, and 1 to 2 points on general user experience for each competitor. That helps you drill down when you move to ranking on parameters.

What's so hard about that? You need someone who knows what's worth writing down. Someone who has done this for over 100 companies. I tend to do a pretty good job at that, which is probably why you're reading this.

Parameters are just the aspects you want to rank. My rule of thumb is a maximum of 5. For a product based business, my go-tos are user experience, design and UI, unique selling props, content and messaging, and pricing. For a service based business: customer reviews, service areas, client onboarding, content and messaging, and how they work and contract policies.

You've got your competitors and some numbers now. Fun. Let's move on.

Your position.

Early on, your focus should be playing to your strengths and generating the most interest in your product. Finding your voice in a sea of "innovation" and "bleeding edge" is hard. Differentiating yourself in an ever growing pile of products is a challenge.

Quick aside, because semantics can matter. Product positioning is about shaping how potential customers perceive a product. Market differentiation is about showing why your product's features beat the competition's. A perspective difference, but worth knowing.

Here's my general advice for any new startup, especially a product. Focus on one problem to start.

That doesn't mean cutting features. That doesn't mean you can't be versatile. That doesn't mean you can't cater to a lot of needs. It means having the right focus, and you only get one in the early stages. Your key problem is the north star for every decision that comes after.

Then the SWOT. Strengths, weaknesses, opportunities, threats. Every "business" person knows the acronym. What makes a good one is the groundwork you put in first. The outside perspective you built from the competitor and parameter work is what separates a SWOT that's useful from a box-ticking one. Play to your strengths. Prepare against your weaknesses. Move on the new opportunities. Stay clear of the threats. Straightforward when you say it like that, but knowing is half the battle. Implementation comes later.

Last for this part, the elevator pitch. Who can say no to a good Shark Tank proposal? Well, a lot of people. Still, this cleans up your position when you pitch to the market. We use a framework. (I know, I know. Sometimes frameworks are good.)

For (target customer), who has (need), (business) is a (category) that (one benefit). Unlike (competition), (business) does (differentiator).

Example, Salesforce: for small businesses without a CRM, who need to control their costs, Salesforce is a CRM that's financially flexible with a low initial cost. Unlike Siebel or managing relationships by hand, Salesforce is quick to set up and easy to use. The example is dated, but it does the job. If you can't fit your business into that sentence, you don't have a position yet.

The trends.

ChatGPT, AI, Crypto, NFT, 5G, IoT, Cloud. What do they have in common? They were the subject of every CES in the past few years.

Trends and fads come and go. The biggest mistake I see founders make is falling for shiny object syndrome. Using new technology can be a real opportunity, but is it for your product? Does your restaurant app really need to mint an NFT with every burger order? Pretty sure someone tried that.

Some tech is good, some isn't, and experimentation matters. But building your whole product around the hot new feature is a mistake. So what do you do instead of headlining features? Headline problems.

Fix the disease, not the symptoms. Use any feature that gets you closer to the problem you set out to solve. Otherwise that hot new feature you promised goes cold next cycle, and you're lost in a sea of apps with nothing to stand on.

If you've listened to enough Decoder episodes, you've heard how many executives get dumbfounded when Nilay asks how they make their day to day decisions. A real understanding of the problem space and your market answers that question flawlessly, if he ever invites you over.

Understanding the trends matters. Understanding why you're building the product is always the answer.

With knowledge of your competitors, an honest read of your strengths, sharp messaging, and a real position to stand on, you've got the best odds at winning the market.

With or without my help – I wish you the best.

And product development is half the battle before you see any success. The other half is your founder duties, fundraising, sales, hiring, all of it, which I'll tackle in another entry.

For now, let's talk about what you actually need to execute on your vision. If you're a founder, chances are you handle product development one of three ways.

1. Hire an agency to handle the software development part.
2. Hire resources directly, through a resource augmentation service or freelance platforms like Upwork.
3. Be technical enough to build the whole damn thing yourself, usually with a technical cofounder.

If you're number three, this probably won't help you much. But if you're one or two, tell me if you've lived through any of this.

With agencies: they dive head first into development without discovery or a plan. Everything happens on an "as needed" basis. They make it very challenging to change directions. They'll agree to a basic build plan with no real drilling down on deliverables. They delay on deliverables in the long term, because there usually isn't a plan to follow. Their documentation tends to be poor from the get go, because most agencies won't invest in building process. They aren't transparent on who's working on your project, you'll never get to see the whole team. And every disturbance in the air has an "additional cost" attached. Change requests are fair. Charging for every single request is not.

With freelancers: finding and sourcing talent in the digital age is a mess. You'll spend more time looking for the "right" people than getting to work. Now you've got a team to manage on top of the gazillion things you were already responsible for, good luck. Freelancers are humans (I know, hot take) and they'll have issues working full time, so you'll get left hanging halfway when something happens. Paying people around the globe isn't as easy as you thought, so now you're a mini accountant too. Communication could be better, everyone "speaks" English, few understand the intent behind the words. And getting the whole team on the same page is hard when you're juggling different technical and cultural backgrounds.

Now, this isn't the story with every agency or freelancer. But these issues are common enough that most startup founders have lived through them.

I've worked as a freelancer myself, and proudly repped my 100% Job Success Score, Top Rated Plus badge, and long-term client success stories. There's a reason only the top 7% get that honor.

So if you're nodding along thinking "Saqib, I've had a great experience with XYZ agency or XYZ freelancer," then more power to you. But if you're nodding in regret, here's the missing piece.

You need a product development plan before you dive head first into execution.

See, much like how Product Discovery is all about what to build, and Market Research is all about who to build it for, a solid product development plan is the how behind executing on your vision. Whether you're confident in your team or lost on where to start, a plan lets you focus your effort on being a founder, not a project manager.

Having done software development documentation for over 100 projects, I know what matters most here. The philosophy is simple, same as always: everything you need, nothing that's extra.

Here's what typically goes into a development plan for an early-stage startup. Note that all of these are developed in parallel, because they're interlinked.

Epics. Defining your product in building blocks. Atlassian puts it well: an agile epic is a body of work that can be broken down into specific tasks based on the needs of customers or end users. That's all the Agile project management you need. We take what's good about Agile and ignore the rest. Epics give you the high-level view of each module that needs building for your first version. Some call it the MVP, some call it never-ending phase 1, some call it the Alpha. Either way, you need the breakdown of everything from authentication to settings. Usually every app has two platforms, a user-facing version and an admin-facing one, and you divide further if you've got multiple user types or admin levels. My rule for defining an epic: limit it to one flow.

Knowing what's necessary versus what's excessive is the whole secret behind efficient execution.

User flows. Here's why I skip stories and tasks this early. Documenting user experience flows is a much better way to approach execution at the start. I like to document three things for each flow. One, the intention behind it (placing an order, scheduling a call, sending a message). Two, the actions required (tapping a contact, adding items to a cart, picking a time slot). Three, the expected outcome (an order is placed, a meeting is scheduled). When you view each flow as intent, action, outcome, it gets really easy to set up the epics that build toward it.

For more complex products you can go further with User Story Mapping, a visual exercise for defining the work that creates the best user experience. Software leader Jeff Patton is the one usually credited with developing and sharing it.

Information architecture. We've got the epics and the flows, time to link them. The IA, a fancy sitemap, is the visual representation of how everything ties together. It helps you spot and fill gaps, and gives you a view of what needs building, in order of priority. Add some color and you can really see what your team will be working on. The key is a navigation flow that just makes sense. You don't want 20 clicks between intent and outcome. You don't want 6 screens before a user sees relevant info. And you don't want modules just chilling in the air like they don't care, everything MUST be linked with purpose. And then, menus. Yes, menus. The menu is where most of the interaction happens for a lot of products, and designing one around user experience is harder than it looks.

Feature prioritization. The biggest mistake startups make is becoming a feature factory way too early. It works sometimes, but mostly it leads to failure. Features make your product usable, but they should never be built "just because." The features you prioritize should fix the disease, not the symptoms. Frameworks for this exist a dime a dozen, and they all work depending on your expected outcome. I keep it simple and use two. The Kano model, which segments customer needs into basic, performance, and delight. And MoSCoW, which sorts features into Must, Should, Could, and Won't. Combine the two and you get a simple, effective way to rank what matters most. We're an early-stage startup here, we can't afford to waste effort. Ruthless prioritization is painful, but it's how you align the product vision with the execution.

Team requirements. Here Agile helps us again. A typical scrum team has a product owner, scrum master, devs, QA, business analyst, and solutions architect. What you need is similar, with a few differences. First, you need designers. UI and UX are two different things, and if you find someone good at both, kudos, otherwise you need two. Second, you don't need separate people for PO, Scrum Master, and Project Manager. A general-purpose project manager can carry the PO role, and a lot of the workload can be shared with the QA and tech lead. My must-have setup for an early execution team:

→ A Project Manager / Product Owner, owning the "how to build." A rotating role you can hand to QA later.
→ A QA who starts on manual functional testing and grows into PO responsibilities as testing needs shrink.
→ Full-stack devs, 3+ years of experience and a portfolio in your stack.
→ A senior dev with DevOps experience as tech lead, running code reviews and helping devs problem-solve.
→ A UX designer to advise on best practices as you go.
→ A UI designer for the visual assets and design, who can double up on business design tasks.
→ Tools: a project management tool (Notion or Basecamp), a communication tool (Slack or Discord), hosting and domains, security like Cloudflare, and API access for the integrations you need.

The thing to keep in mind: at this stage you want people who go wide, not deep. As you grow, you hire specialists. I've watched founders get distracted hiring DevOps specialists and cyber security analysts when there isn't even a product ready yet. If you genuinely need an expert at some stage, bring them in fractional or as-needed. Otherwise stick to the breakdown above and budget accordingly.

So why listen to me? I specialize in filling the gaps founders hit in their product on the way to PMF. I'm a strong believer that most startups don't need a dedicated product manager in the early stages. They do need product help.

With your modules mapped, your features prioritized, your information architecture visualized, your user flows documented, and your team needs laid out, you're ready to execute with a real plan.

With or without my help – I wish you the best.

What sets an agency charging $30/hr apart from one charging $100/hr?

Here's the road most agencies travel. You start providing services. You figure out how to win clients. You figure out how to scale a team. You keep getting engagements, you sell more than you can handle. Then you burn out and stop.

I come from the freelancing world, so I know that road well. It's the one every freelancer trying to become an agency ends up on. But I've also spent a lot of time in corporate, and the agencies you see there don't travel it.

Why? Because they've figured out three things. They don't take on whatever walks through the door. They prioritize quality over quantity. And they know their niche, they don't sell to "everyone".

There's a reason the average lifespan of a freelancer-turned-agency is around 4 to 6 years. The owner sees revenue spike, tries to max out the profits, and never reckons with the long-term cost of all the small mishaps that keep piling up.

If you're nodding along, here's the answer to the question at the top.

What separates $30/hr from $100/hr is process. What separates $100/hr from quarter-million-dollar contracts is branding. And before you go anywhere near branding, you have to nail the basics. Process is what keeps you from dying out. Branding is what gets you to the next scale.

A couple of assumptions before we go further, since this is an article and not advice tailored to you. Everything below is for software development agencies, the ones shipping websites, web apps, mobile apps, and similar work. A lot of it transfers to other services businesses, but that's not who I'm writing for. And this is for small agencies, early in their life, doing somewhere around $10,000 to $30,000/month. Bigger than that and you've probably outgrown it. Smaller than that and you need to fix your sales first.

So let's talk process.

Picture a standard small setup. The owner. One or two project managers. Three designers, three developers, one QA tester, and a couple of people on sales and marketing. The whole thing falls apart in the same predictable places, so those are the places worth standardizing.

Communication. This is the one most agencies overcomplicate, and the number one reason comms fail is inconsistency. One day the owner emails the team, the next day they Slack, the third day they call, only to find out the answer was sitting in an email from two days ago.

Keep it simple and structured. Dedicated channels by priority. Highly urgent goes to direct comms like Slack or Teams. Documentation-only goes to your PM tool. Client comms go to email or a client portal. Daily check-ins on Slack. Have a way for everyone to be notified when a task is assigned to them, and use tools that actually support an "assign" function. Give the team a real way to submit feedback to the company, always, because "DM me if there's an issue" is not it. Run a daily standup for small teams, twice-weekly for large ones, and keep the purpose narrow: clear blockers, that's it. And every project gets its own dedicated communication space. Don't mix and match.

Project and task management. You're delivering projects, so a PM tool is non-negotiable. Notion, Basecamp, Asana, Monday, I don't care which, as long as the basics are met. Requirements laid out. Tasks drilled down. Team assigned. A way to post updates, a way to flag blockers, a way to see everything from a bird's-eye view.

Without going full Agile, and please never go full Agile, every item should be straightforward. Each task needs a definition, a criteria for done, an end goal, and a realistic due date. If something can't be finished, there needs to be a reason on the record.

Then the most important rule. Anything related to a task MUST be documented on the task. Not in email, not over Slack, not on a call. Document on the ticket first, mention it elsewhere second, or you'll lose the thread faster than you can count to 3. And there should always be a "look at me, I'm in trouble" place, a flagged spot for blockers, and it gets looked at first in every check-in.

A lot of folks adopt enormous frameworks for 5-page websites. Start small, then scale. If you're building genuinely complex software, invest upfront in documenting everything before you commit to the work (Roadmap, before you build).

Client management. This is the bread and butter, and here's the number one mistake fresh agencies make: communicating too much.

Too much? Isn't that a good thing?

No. If you send a client 10 messages a day with nothing meaningful in any of them, two things happen. They start expecting an update every two hours, and they get desensitized to the ones that actually matter. Notification fatigue, same concept.

So have one check-in a week, no more than two. Over a call, and the client shows up, because that's what keeps both sides accountable and gives the team enough room to come back with real progress. Same agenda every time. Here's what we've done, here's what's next, here's what we need from you, then whatever else the client wants to raise (keep it short). After the call, always send a written recap with the recording.

And put the right people in front of the client. Not the developer, not the designer, on their own. Their job is to build, not to take heat on a Tuesday. You need a PM, or someone who can manage clients, to shield and filter what gets passed on as a requirement. Too many agencies put people on the frontlines who have no business being there, and that's a great way to lose good talent.

One more thing on clients. Document every word, sort of. Clients change their minds, and it's almost never on purpose. They're just excited, and excitement breeds miscommunication. Anything that needs to be on the record gets recorded. And learn to show progress when there's nothing visual to show. Design moves fast and looks fast, so clients assume development will too. It won't. If you have 10 designs ready, share 2. If 3 modules are built, share 1. Pace the feedback so nobody approves something they'll reject later.

That's the process layer. Now the day-to-day, the part that's actually yours as the owner.

The number one enemy here is context switching. Multiple projects, team members on multiple things at once, and the moment you pull out process and organization, you get chaos and missed deadlines with no obvious cause.

So a few habits. Keep a bird's-eye view of every active project: who's on it, when the last documented client check-in happened, current workload, expected delivery of the current phase, anything pending feedback, anything on fire. Say hi to the team every day, it's simple and it works, and it doubles as a quiet check on whether things are getting documented where they should be. Pick 2 projects a day to deep-dive, 10 a week, easy for one person to hold. If you find a problem, don't start a message war and micromanage it. Gather your findings and bring them to the weekly check-in, so there's time to correct and less drama. Watch your tools' activity history for a lack of activity, not for more or less of it. And keep your ears open for feedback, because in a small team most blockers come down to transparency or documentation, not some $10,000 CRM.

If you're diving deep into every line a team member writes, that's not diligence, that's a failure of process or a failure of competence. Install the checks yourself at first, then hand them off to your team or your tools.

Now, the part where I cross over to the other side of the table. I work with founders, and here's the complaint I've heard most:

They went straight to development without any discovery. Then they failed to deliver what was promised. I felt like I was lied to.

And honestly, how can you blame them. Plenty of agencies claim they "do everything under the sun", and clients fall for it, and the cycle of over-committing and under-delivering is the single biggest reason agencies get a bad name. Dig in and you usually find the same thing: no process, no visibility, no communication, just a fancy website that talked someone into paying six figures. That's an agency on the verge of an exit. You can only stack up so many unhappy clients before the road closes and you end up selling courses on how to run an agency.

If you don't want that ending, start on the right foot. Understand your clients as deeply as you can, which also means turning away the ones who won't be a good fit. Use an onboarding questionnaire and an intro call to learn the things that matter: the client's background, their past experience with software development, whether the resources exist for the project to succeed, whether it's in an industry you can deliver on, how many stakeholders are involved, and whether they'll actually give you feedback and approvals on time.

Because when you start out, you take anything you can get. To level up, you niche down. The one strategy that works for any business, any product, any agency, is to figure out what you're good at, figure out who needs it, and sell a whole lot of that. Saying you're good at everything just means you're exceptional at nothing.

Figure out your core, build your services around it, target clients who fit, and upsell from there if it makes sense. But your branding, your process, your messaging, all of it, should point at one consistent goal: a solid solution to a defined problem.

Process is unsexy. Nobody tweets about it. It does, however, double your rate.

With or without my help – I wish you the best.

Today I want to talk about MVPs. The word I keep hearing over and over. I guess that's what you get for working with startups all year round.

Doesn't help that nearly everyone using the term is using it wrong. That's what I want to fix today.

Let's start with a quick Google.

A minimum viable product is a version of a product with just enough features to be usable by early customers who can then provide feedback for future development. Good ol' Wikipedia.

And right there is where the trouble starts. What is "just enough"? Enough for the budget? Enough for the timeline? Try defining "enough" to a founder. Good luck.

That definition was fine back when building software was an arduous slog. You'd grind until you hit a level of polish you felt okay launching with. But these days, with AI, no-code tools, and outsourced devs a click away, "enough" doesn't define an MVP anymore.

Here's my take. Love it or hate it.

MVP is a mindset, not a formula. The mindset of solving one core problem, in increasingly better ways as the product grows. You find a problem, you build a solution, and whatever solves the problem becomes your MVP. In most cases.

So the real thing to solve for is the problem itself. What makes a problem a good problem?

In product terms, a good one is a problem that:
→ Hits a real market. Actual people, lots of them.
→ Is feasible for you to solve in your current state.
→ Is focused. Targeting specific pain points. Niches be riches.

And the big one, for founders, maybe you: do you actually care about solving this? Or do you just see dollar signs in your eyes, Patrick?

Got a good problem? Let's keep going.

The resources are plentiful these days, which is exactly how you end up in analysis paralysis picking your path. Here are my top 2 ways to think about building an MVP.

1. Start a community.

If you genuinely care about a problem, odds are a community for it already exists. If not, go build one. Talk about the problem, raise awareness, get people behind you. Before you write a single line of code, get your first 100 supporters.

That's the most effective way to bootstrap an MVP right now. Start a blog, a newsletter, hit social media. Endless ways to build a community. If the pain point is real enough, open a paid one on Skool for all I care.

Building a community, and then building inside it, is the best way to make an MVP these days. No question.

2. The service-to-product route.

Know how to solve the problem yourself? Then become the product yourself. Starting a services business is a solid middle ground before going full product, especially your first time around.

Most pain points today can be solved with a behind-the-scenes service. Look at the established product companies. 10up, 37signals, Automattic. They all started as agencies, served clients, spotted a pattern, then built their own products.

Services don't sound sexy these days, I know. But it's better to build a product with the experience of building than without it.

Got the pain point and an approach? Then build your MVP like a skateboard. You've probably seen the image.

I love it. I mean, I don't think any skateboard company sells cars. But that's not the point. The point is the mindset. Solving a problem consistently, just in increasingly complex ways for you, and increasingly convenient ways for your users.

A lot of people think an MVP is an "incomplete" version. Wrong view. An MVP is the most feasible version of you actually solving the pain point. It's built to gauge interest, validate the idea, test the waters.

Stop thinking of an MVP as the "Product." It isn't. It says so in the name. It's barely viable.

A "Product" is a business. Money comes in, or there's a very solid chance it will once certain conditions are met, like 10k users on a trial. That difference matters more than ever right now.

So, make MVPs great again. Shift the focus from deliverable to mindset.

If you can build a community, learn from the feedback. Do things that don't scale. Get on calls. Work with the people who'll make this thing work long term.

If you're running a services business, watch for patterns. Instead of selling the 20th service, focus up and niche down. Turn services revenue into your product-development fund.

My favorite line from the skateboard piece:

A good product manager, you, the founder in this case, doesn't dictate solutions to the team. They define the problem completely enough that the team can design and build the solution.

All of this is just to hand you a new perspective. If you still think an MVP should be stuffed with features, you do you. But the goal here is to leave you a little better equipped on how to approach product development.

With or without my help – I wish you the best.

By now everyone knows the line: a good elevator pitch is short, to the point, and lands with impact.

So why is it that every time I ask a founder to give me an elevator pitch for their business, they just stumble?

Funny story. A while back I had a founder who was supposedly running 5 startups, side by side. I went in with my usual opener. Hey, explain your business to me in an elevator pitch.

You know what happened? He couldn't remember the names of all 5 of the "startups" he'd started up.

That's what happens when you move with trends instead of a vision.

If you're a founder and you can't explain your business in under 2 minutes, you've still got a lot of finding to do.

A good elevator pitch isn't just you knowing how to sell yourself. It shows you care about the problem you solve. It shows you're aware of the market and the competition. It shows you have a vision beyond the current trend. And it shows you've done your preparation.

Here's a story from a CRM client consultancy of mine.

The market is full of CRMs. My client wanted to launch one that was actually focused on the people who use it. To this day, most CRMs are optimized for data, insights, workflows. Stuff that matters to the leaders. But for the employees? Learning a modern CRM is a masterclass in itself.

Anyone who's worked sales or support in a corpo environment knows this. A CRM can kill all your will to get any real work done. So what did I tell my client?

Simple. Aim to cure the disease, not the symptoms.

Everyone wants to be the next Salesforce. Nobody wants to be the next Basecamp, a non-VC company worth millions.

If you really care about solving employee happiness, say so, and stick to it. Instead of standing on features, stand on your vision. Stand on the long-term goals. Stand on the problems you want to solve.

Instead of "we're a CRM that uses the power of AI, plus feature X and feature Y," say "we're a CRM that works for the people who actually use it at the end of the day."

And people will care.

Most startups fail right out of the gate because they commit to standing on features instead of a vision. Then a day comes when that feature isn't the hot new fad anymore, and they die out.

Now, knowing the value you provide.

If you're not sure what value you're offering, why would anyone buying from you be confident in you? Value comes up in almost everything I write, because at the end of the day, if you want to run a successful business, providing value is what makes you, well, valuable.

So here's a bare-bones process to figure out your value proposition.

First, who are you selling to, and who's eating the cost? These can be different. Especially in B2B, you sell to the users but the business pays. Your messaging has to consider both sides. If you know the industry, the type, the persona, even better. Don't overcomplicate it. Stick to a few core groups, max of 3. The fewer and more detailed, the better.

Second, define the problem. Don't just state it. You have a problem to solve? Why is it a problem? Do you have data to back it up? Feedback? What makes it a problem? Ask as many questions as you can to refine the thing you're setting out to solve.

It's easy to point out faults. Easy to spot problems. Hard to find problems worth solving. Your problem needs demand. It needs definition. It can't be something you dreamed up in a silo.

Most founders I've met had a career in a specific industry, kept a list of problems they faced, and set out to solve them. That can be an excellent starting point. I've still seen too many fail, simply because they confuse their own experience with everyone else's nodding heads. (We'll go deeper on problem definition another time. For today, the takeaway is: solve problems worth solving.)

Third, sell the outcomes, not the features. So you have your problem 1, 2, 3, and your wannabe product has feature 1, 2, 3. Then what? You spam the features and call it a day? Nope. Most folks don't care about the specifics.

A person getting their car repaired doesn't care how the engine works. A person ordering at a restaurant doesn't care how the kitchen works. A person charging their phone doesn't care how many amps the battery holds.

They care about outcomes. Car repaired quickly and within budget. Food served on time and good. Phone that lasts once it's charged.

So why is it that when you build a startup, you don't commit to outcomes? Because you don't put yourself in the customer's shoes. For a moment, forget you're the founder. Forget all the work it'll take to build this thing. Most folks don't care how it works. They only care if it works.

Painful, but true. Your job is to cure the disease, not the symptoms.

Now let's bring it under one roof with an elevator pitch.

You've got your problems. You understand your value. You know who you're selling to. Let's make you a Shark Tank success, with the Elevator Pitch Framework.

I rarely use frameworks, and trust me when I say that. As a PM who's supposed to know the top 20 frameworks cold, I seldom pick one, and even seldomer do I suggest one. But the Elevator Pitch Framework is the explain-it-to-me-like-I'm-five your startup needs. Easy to understand. Structured for success. And you can keep iterating on it.

Here's the deal. It helps you answer this:

FOR (target customer), WHO HAS (customer need), (business name) IS A (market category) THAT (one benefit). UNLIKE (competition), we (unique differentiator).

For. Who's the target customer? You need a specific category to fit your services and working style.
Who. The need the business promises to fill.
Is a. The specific category of services or product you're offering.
That. The benefit you provide. (This is the value part.)
Unlike. Who you're competing with.
We. What sets you apart.

A worked example, using Salesforce. A bit dated, but the structure is the point.

For small businesses without a CRM, who need to control their costs, Salesforce is a CRM solution that's financially flexible with a low initial cost. Unlike Siebel, which requires large infrastructural setup, or managing customer relationships by hand, Salesforce is quick to set up and easy to use.

Wasn't that easy? And the best part: you can keep improving each statement over time, and swap them out when the time is right. Next time, no overhead baggage.

So why does this all matter?

Figuring out your elevator pitch is probably the highest-ROI exercise you'll do in the early stages of a business. It serves as your guiding light toward your mission and vision. Your guard against doubt and imposter syndrome. Your shield while you work on your uniqueness. And most importantly, it helps you turn an idea into reality.

Without it, you're lost on the true purpose of your business. Without it, you doubt the value you bring. Without it, you'll keep thinking to add AI, no AGI, no 6G every other quarter. Without it, your idea stays a dream.

Happy pitching.

If you want the longer version of this, I've written about market research as the work that feeds it. The pitch is only as good as the research underneath it.

With or without my help – I wish you the best.

Why should I even bother making a product? There are already so many options in the market.

And over time, my go-to answer to the go-to question became a question of my own.

Ever been to the supermarket? How many brands of mineral water do you see? How many egg brands? Why are 10 different companies selling me tissue paper?

Corporate consolidation aside, if you have a decent product idea, chances are there's plenty of room in the market for it.

Comparison is the thief of joy. Most folks picture Apple, Google, Netflix, and forget the garages those companies started from.

Most businesses are below $10M ARR. Even more are under $1M. And they're fine.

If you have a good product, the thing to grasp is this one fundamental truth: there's a huge gap in the market. To compete inside that gap, you've got two moves.

Provide more value for the same cost.

Or provide the same value for a lesser cost.

That's it. Fundamentally speaking, it's that simple.

Now here's where most products fall apart. They're built around a single feature. If your startup stands on one feature, you're bound to fail. There's a reason we say value proposition when we talk about messaging.

Your value should be aligned with a core problem you're setting out to solve. The feature, the tool, the skill you use to solve that problem, that part is always evolving.

In the short run, standing out on a feature might be fine. In the long run, you have to solve problems and sell outcomes.

Customers don't care if your product has an XYZ feature. They care if your product solves their XYZ pain point.

Features don't connect with customers. Stand on features and you risk being just another brand on the shelf. Value communicates emotion. Stand on the problems you solve and you stand out from the bunch.

Features change. Industry shifts all the time. Your shiny AI feature today is a fad feature tomorrow.

Value stays. People's problems tend to stick around, and finding new ways to solve the same problems is the whole name of the game.

In the product world there's a long-running debate, Outcome vs Output. Think of Value vs Features in the same way. You want to sell the promise of your product, not the spec sheet.

That said, features still matter. They just aren't the only thing that matters. Which brings me to the two terms everyone confuses.

Product positioning is about shaping how potential consumers perceive a product.

Market differentiation, or product differentiation, is when a company uses strategies to show why its product features beat the competition's.

(That snippet is lifted from my own product discovery as a service page.)

Here's my general advice for any new startup, especially a product one.

Focus on one problem to start with.

That doesn't mean you cut features. It doesn't mean you can't be versatile. It doesn't mean you can't cater to a lot of needs.

What it means is having the right focus. You can only have one right focus in the early stages. The key problem you've identified becomes your north star for every decision you make in the business.

The two terms pull in different directions, and that's the point.

Product positioning carves out a distinct space in the customer's mind. Market differentiation makes the product itself unique by focusing its benefits.

Positioning is catered to your audience. Differentiation is about the product.

Positioning can be short-term and flexible. Differentiation often involves ongoing development.

Positioning is about image and identity. Differentiation is about features and benefits.

So in the end, you need to understand three things clearly:

→ What value am I bringing to my customer base?

→ How am I positioned in the market as an attractive option?

→ Is my product offering features and benefits to differentiate on?

Hopefully this did a decent job of conveying why value, positioning, and differentiation matter.

The goal isn't to make you stop executing on ideas. It's to give you direction on how to improve them. The market is vast, and there's always room for a product that offers more value or solves a specific problem.

And whenever you think about Apple and the rest, understand one thing.

They didn't get where they are by doing extraordinary things. They got there by doing ordinary things, for extraordinary lengths of time.

Keep executing on your ideas. Just with better direction.

If you want to go deeper on the market side of this, I wrote a whole piece on market research.

With or without my help – I wish you the best.

If you're tired of statements like that getting thrown around your circle, this one's for you.

This is the issue that left bruises in my mind working at corporate. The paradox of strategic planning.

Strategy and planning. Why do folks keep using these two unrelated things in the same sentence?

You could say it's all semantics. But when it comes to being successful with your business, the semantics matter. And the paradox of strategic planning is very much a real thing.

Strategy is not planning. Period.

Having done good planning doesn't mean you have a good strategy. If you're on a team where "strategic planning" gets thrown around, understand one of two things. Either the people using it don't care much about being specific. Or they're substituting a fancy-sounding term for a lack of competence.

If you're in the early stages of your business, this is really important to get.

Strategy is everything you'll do to win with your business.
Planning is everything you'll do to execute in your business.

The two are fundamentally different, even though people use them interchangeably.

Strategy is the vision. How you'll win in the market. High-level, subjective, thematic. It sets the direction for your organization.

Planning is the detailed, calculated, outlined execution of that strategy. The set of steps you take to actually get there.

To put it simply:

→ Strategy is more visionary. Planning is more calculated.
→ Strategy sets a direction. Planning gets you to a destination.
→ Strategy is built around limitations of your environment, out of your control. Planning is built around constraints like time, resources, and budget, in your control.
→ Strategy is harder to track with metrics. Planning is easier to track with metrics.
→ A good strategy needs context. A good plan needs detail.

Both have their place. Just understand that strategy should be set to outcompete, and planning should be set to make progress.

So what should you actually do to win?

At the foundation, when it comes to providing value, you've got two moves:

1. Provide more value to your customers at the same cost.
2. Provide the same value to your customers at a lower cost.

And if you can figure out how to provide more value at a lower cost, that means you've made it.

In the short term: when you're figuring out your strategy, figure out how you're maximizing customer value by picking 1 or 2.

In the long term: to outcompete as a business, your strategy needs to eventually result in you commanding "Powers."

Those powers are scale economics, network economics, counter-positioning, switching costs, branding, cornered resource, and process power. We'll explore them properly in the series when the time is right. For now, you can go deeper on Hamilton Helmer's 7 Powers if you want to chase the idea down.

Here's the gist of all of it. Just planning is a comforting place to be. It feels nice to make to-do lists, and kanban boards, and notion docs. But at the end of it all, if there's nothing to show for it, have you really made any progress?

A few questions I'll leave you with:

1. Do you fully understand the difference between planning and strategy?
2. Have there been moments in your life where you felt stuck in motion without action? List them out.
3. What do you genuinely believe you're doing better than your competitors? Does your advantage line up with any of those 7 powers?

If the answers come hard, that's fine. Soon in this series I plan to cover a bunch of topics that'll help you build your own strategy and line it up with the other parts of your business.

With or without my help – I wish you the best.

When I started writing about Product, Business, and Career, I never thought a day would come where I'd be writing like this. But here we are.

So today I'm moving to the next stage. The Rift.

What is it? Mostly a consolidation effort.

I've written a lot, across a lot of different platforms. I want to bring it all under one roof.

But for now, the way any early-stage business needs time to find product-market fit, The Rift is an exploratory exercise until it finds the right one.

The Rift is for exploring early-stage pains at the intersection of Product, Tech, and Business.

A bit of background.

Over the past few years I've published over 100,000 words in every format you can think of, across three main areas.

Product. Content for early-stage founders to help them with their product gaps. I think Product Management needs to be scaled down in scope to make sense for people who are just starting out. My writing was my way of pointing at the parts that actually matter when you're launching a startup.

Business and Career. If you know my history, you know I jumped a lot of hoops, and had some success doing it. The Wandering Pro (TWP) was my attempt at sharing what I'd learned with people in similar struggles. Based in Pakistan, opportunities are sparse, and standing out is even harder. Learning how to go from a 9-to-5 to a freelancer to a business owner was a journey worth sharing.

Tech. Last but not least, tech is still at the heart of everything I do. I grew up in an environment where passion tends to die the moment you turn 18. I kept the embers lit. SK NEXUS (SKN) was my outlet to write about what I want, and to say what I think needs saying when it comes to tech. There's a massive gap in content from the Pakistani perspective, and I wanted to fill it.

Now I want to bring it all together. Here's the what, the who, and the why.

I've written long form, short form, fact-based, opinion-based, just about every kind of content there is. For this journal, I want to keep it straightforward.

Each entry covers a topic in Product, Tech, or Business, aimed at unlocking a new perspective or handing you new knowledge. Over time, with feedback, I'll figure out the definitive direction. For now, the format stays pretty open.

Who's it for?

Everyone. JK. No content, product, or business is ever for "everyone." But having spent time in the business world, I've got a decent starting point.

Founders and business owners. I still work mainly as a Product Management service provider (Upwork), close to owners and founders. That puts me in a good spot to share things that help if you're standing where they stand.

Career professionals. If you work in tech, knowing how Product and startups actually work is a solid way to upskill. This should hand you a few new perspectives as you read.

Tech-heads. Even if you don't care about business or career, tech is everywhere. Understanding how it ties into the things you already use is knowledge worth having.

So, why do I want to write this?

There's a thing about standing on the shoulders of giants. Every next generation has advantages the previous one didn't.

I had a lot of advantages growing up close to tech and working close to businesses. Now I want other people to take advantage of that too.

And I genuinely believe I can provide value to others, while others make this a sustainable effort for me over the long run.

From here on, my effort goes into writing for this. The best way to keep the show running is by showing up.

Thanks for tagging along.

With or without my help – I wish you the best.