@Stephanie Liu
Last updated: March 31, 2026
These are the values that shape how the product team works at Nourish. They're opinionated by design. This is not a list of things any thoughtful PM would say, but a clear statement of what we actually believe and how we make hard calls. If you're a candidate, this is what you're signing up for. If you're already here, this is the bar.
What we don't build is just as important as what we do build. Every surface we add is a surface we maintain, support, and staff context around. We are not building the most comprehensive tool — we're building the right one.
Before anything makes in onto the roadmap, we ask: what is the core value being delivered, and is this the most direct path to it? Does the expected value this feature is going to deliver outweigh the additional complexity and maintenance costs? If we can't answer that clearly, the project isn't ready to build.
AI has changed what it means to do product work. The gap between a PM who can spin up a prototype in v0, use an MCP to do their own data analysis, and push a small config change and one who can't is widening fast, and we expect our PMs to be on the right side of that gap.
This doesn't mean PMs should be doing design or engineering work. It means the tools available today make it possible (and expected) for a PM to take a feature from rough idea to testable prototype without pulling in design and engineering for every step. We expect PMs to be able to mock before they spec, query before they ask, and validate before they build.
We use data to maximize our chances of hitting ambitious goals, not to rationalize staying close to the baseline. We take big swings when the strategic case is clear, and we use experimentation to find the fastest path to making them land. We don’t point to the data outcomes that a subpar product delivered as a way to shield ourselves. Before anything ships, we name the metric we're trying to move and the threshold that would change our mind. Without that, we are fooling ourselves into calling incremental improvements a win.
The teams that build great products know when to run a tight experiment and when to make a directional call. We do both. Playing it safe every time isn't prudent, it's just a slower way to lose.
We do not wait for certainty before building. A well-aimed product shipped this week beats a perfect one shipped in three months. But speed without conviction is just thrash — we don't ship to learn if what we're shipping isn't worth learning from (if you ship shit, you only learn that people don’t like shit). Gain conviction in the direction right first, then move fast.
This makes scope-cutting a core skill, not a compromise. If something is too big to test cheaply, we haven't done enough thinking yet. Features that are hard to undo get more scrutiny before they ship, not after. The MVP isn't the lazy version — it's the version that most efficiently surfaces whether our hypothesis holds. When scope creep shows up, it's usually a symptom of not having named the core bet clearly enough.