Nathan Latka

So roadmap-wise, what's the process for communicating that?

What's the process for talking about it and getting feedback from people who might know more than you about if that's a good idea?

Because customer success will be like,

You probably should not build that because they want this other thing, or maybe you should do this first.

But only if you give them the space.

So give them a seat at your product table right from the beginning.

And then document shit.

Like how many times have you built things and it's like that one guy in the corner who knows everything about it, and if that person leaves, man, we are so screwed, right?

They're the only one that knows.

If you have somebody like that or a group of somebodies like that in your organization...

Give them time on their schedule to brain dump a bunch of it because you never want to be in a position where if somebody leaves your company, y'all are screwed, even the CEO.

So the sooner you can get into documenting that, especially about your product and how decisions are made and what the process is by getting things on the roadmap, the better off you'll be.

Yeah, so to your point, there's a good way to have a balance of new features and fixing things that already exist.

But given the choice, fix things that already exist because that will keep loyalty of your current customers unless you're making a huge pivot.

But if you're not making a huge pivot and you don't have actual skim in the game from people who, like if Microsoft calls and says we'll give you $8 million to build this feature, build the feature.

That's fine.

That is rarely the case.

Don't do it on promises.

Trust that the people who use your product really do want it to succeed, and they just want it to work better for them, right?

I didn't spend five hours with Amex because I love them.