Certified Doesn't Mean Qualified | Andru Estes

Got it.

But how do you personally evaluate the difference between over-engineering and smart future-proofing?

Over-engineering and smart future-proofing.

All right.

This is, uh, I'm hop- hopefully I do my wife proud here.

She's a product manager, and if she hears this, and I give the wrong answer here, she's gonna murder me.

But [laughs]

[laughs]

No. Um, I think that's a very fine line.

I think, for lack of a better term, really finding out in a well-defined minimum viable like product, right, or whatever it may be to get to market.

Let's assume you're just coming out with something new, you need to get to market.

It's very easy to want a perfect solution, quote-unquote, perfect solution right out of the box, first time go around.

First of all, not gonna happen, but you can try and plan for it, right? And then you're just stalled out for months and months and months, and then it doesn't go as planned anyways.

So finding and defining a well-defined roadmap is huge.

This is the bare minimum we need to get to market, whatever it may be.

We need a reporting feature for these customers, right? And then from there, you wanna make sure you don't box yourself in.

So from a future, smart future-proofing standpoint, are you giving yourself some leeway to either pivot? Are you building in with the idea that, "Hey, we are-- we've been hearing from customers that they want potentially feature A, B, and C, so let's start prepping for that, but we're not gonna throw all of our resources at it," right?

Mm-hmm.

So you're, you're kind of prepping yourself to be flexible more than anything, and take a high level approach after that minimum viable aspect, if that makes sense.

So a-again, like 'cause things change, uh, I mean, six months right now, your customer might be like, "Ah, we don't need, we don't need those reports actually," right? "We, we found something else.

We actually need X, Y, Z instead of A, B, C." And you're like, "All right.

Well, hopefully I didn't pigeon myself or pigeonhole myself into this one aspects." So you really wanna be sure you provide that flexibility, and then just high level approach.

I, I think that's where a good product team comes in, I'll be very honest.

And again, I'm a little biased 'cause my wife is in product.

But they can kinda be that liaison and be like, "Hey, do you guys really need this like right now? Or is that something we can kinda put in the, the backlog for later on and have our engineers look at it?"