I'm Not Just Managing the Product. I Can Build the Damn Thing.

Product roles are weird.

Depending on the company, a Product Owner or Product Manager might spend their day writing requirements, prioritizing a backlog, talking to stakeholders, translating between business and engineering, and moving Jira tickets around like an extremely expensive game of Tetris.

And yes.

I can do all of those things.

But that’s not what I think sets me apart.

What sets me apart is that when I’m sitting in the middle of a conversation between the business and engineering, I actually understand both sides.

And more importantly?

I can build the prototype.

I’m Not Trying to Be the Engineer

Let me make this very clear before an engineer somewhere starts aggressively typing.

I’m not trying to take a true engineer’s job.

I don’t want to.

Engineers bring a level of depth, architecture, scalability, security, performance, and technical craftsmanship that I respect the hell out of.

What I do want to do is make their job easier.

I don’t want to walk into an engineering meeting with a vague idea, a Figma file, and:

“Soooo… can we build this?”

I’d rather show up with something that’s 95% of the MVP.

Here.

Click it.

Break it.

Here’s the workflow.

Here’s where the data comes from.

Here’s what the user needs to accomplish.

Here’s what I hacked together.

Here’s what I know is ugly.

Now make it good.

That’s where I think Product can become incredibly powerful.

Nobody Has to Figure Out Where the Hell to Begin

The blank page is expensive.

If I hand an engineer a paragraph describing what a stakeholder thinks they want, they now have to help figure out the product and engineer the product.

That’s a waste of engineering talent.

I’d rather burn through the ambiguity myself.

I’ll prototype it.

I’ll change the flow six times.

I’ll discover that the original idea was stupid.

I’ll find out that the API doesn’t return what I thought it returned.

I’ll realize we need three fields instead of twelve.

I’ll let stakeholders click around and tell me:

“No, that’s not what I meant.”

Great.

Tell me now.

Not after an engineer spent three weeks building it.

By the time something gets to engineering, I want as many of those questions answered as possible.

I want to hand them the 95% MVP and say:

“This is what works. This is what doesn’t. This is what we learned. Now I need you to turn it into something we can trust.”

They don’t have to figure out where the hell to begin.

They get to start with a problem that’s already been explored.

I Don’t Throw Requirements Over the Fence

I don’t particularly enjoy this version of Product:

Business has idea → Product writes ticket → Engineering builds ticket → Everyone discovers three weeks later that the original idea didn’t make sense.

That’s expensive.

And avoidable.

I want to understand what’s actually happening.

What’s the business problem?

What does the user need?

What data already exists?

What systems are involved?

What are the technical constraints?

Is this actually a feature?

Or are we about to spend six weeks engineering something that could have been solved with a workflow change?

Sometimes the best product decision is deciding not to build the product.

I Speak Engineer

I don’t mean that I know every framework, infrastructure pattern, or programming language.

I don’t.

But I understand enough to have a real technical conversation.

I understand databases, APIs, authentication, front-end versus back-end, data structures, integrations, infrastructure, dependencies, and the dreaded:

“Well, technically…”

And I actually like that conversation.

Because engineers shouldn’t have to translate everything into kindergarten-level technology language just because someone works in Product.

Tell me why it’s difficult.

Tell me what’s going to break.

Tell me why my prototype is held together with duct tape and optimism.

That’s exactly why you’re here.

Then let’s figure out what deserves to become production software.

I Also Speak Business

This is the other half.

I can turn around from an engineering conversation and explain the exact same problem to someone who does not care what an API is.

And they shouldn’t have to.

They care about what we’re solving, how long it’ll take, what it costs, what the risk is, and whether it’s actually going to make their life better.

That’s the job.

Not proving that I know technical words.

Translation.

AI Has Made Prototyping Ridiculously Fast

This is where AI has fundamentally changed Product for me.

The distance between:

“I have an idea.”

and:

“Here, try this.”

has gotten really small.

I can use AI to scaffold something, work through logic, explore an unfamiliar library, build an interface, connect an API, test a workflow, throw it away, rebuild it differently, and keep going.

Yes, sometimes I’m vibecoding.

I will happily own that.

I’m not pretending my prototype is beautiful production-grade engineering.

That’s not the point.

The point is that yesterday we had a meeting and a hypothetical.

Today we have something you can use.

And now we’re having a much better conversation.

A Prototype Is Supposed to Answer Questions

That’s the distinction I think gets lost.

I’m not building prototypes to prove I don’t need engineers.

I’m building prototypes so engineers don’t have to waste their time proving the product concept for me.

There’s a massive difference.

My prototype answers:

Does this solve the problem?

Does the workflow make sense?

Can we get the data?

Will users actually use it?

Did we miss something obvious?

Is this worth investing engineering time into?

Once we know those answers, then engineering can do what engineering does best.

Architecture.

Scale.

Security.

Performance.

Maintainability.

Testing.

All of the things that separate:

“Look! It works!”

from:

“Yes, this can safely run our business.”

Those are not the same sentence.

And I know that.

That’s What Sets Me Apart in Product

I don’t think Product should just be the messenger between people who understand the business and people who understand the technology.

I want to understand both.

I want to be able to sit with a stakeholder and find the actual problem.

Walk over to engineering and understand the constraints.

Open my laptop and prototype the idea.

Put it in front of users.

Break it.

Change it.

Prove that it’s worth building.

Then hand engineering something tangible instead of a treasure map.

I’m not trying to replace engineers.

I’m trying to make sure we’re using engineers for engineering.

Let me deal with the messy beginning.

Let me turn the idea into something real enough to evaluate.

Let me get us 95% of the way to an MVP.

Then give it to the people who can take that last 5% and turn my prototype into something that’s actually production-ready.

Because, as it turns out, that last 5%?

That’s usually where about 95% of the engineering lives.