The Four Things That Matter Most

Why Most People Skip the Foundation and Regret It Later

I spent about eight years working in project management before I stopped trying to optimize for speed and started optimizing for clarity. The turning point wasn't a certification or a fancy tool. It was a product launch that failed because we had perfect sprint velocity, zero technical debt on paper, and absolutely no idea who we were building for. We shipped on time. Nobody used it. That stung more than any missed deadline ever has. After that, I stopped chasing methodologies and started tracking what actually moved the needle. Over the next decade, across startups, enterprise rollouts, and a few disasters that deserved to happen, four categories kept reappearing. Not as buzzwords. As hard constraints that dictated whether something lived or died. If you strip away the frameworks and the LinkedIn advice, these are the things that matter most.

The Four Things That Matter Most

1. Who This Is Actually For

Not your target market segment. Not your buyer persona deck. The actual human being who opens the thing you built and decides whether it earns five more seconds of their attention or gets deleted. This distinction matters because persona work is often done by people who aren't talking to customers, and "target market" is a statistical abstraction that doesn't feel like a person until you sit with one for an hour. I worked on a healthcare compliance tool once. We had twelve different user archetypes mapped out in a beautiful Miro board. The actual person using the software at 11pm before a regulator audit was a mid-level operations manager named Linda who didn't care about our "seamless workflow" and just wanted to export three reports without clicking through seven menus. We redesigned the export flow in two days after shadowing her for an afternoon. Usage of that feature jumped 340% in the next month. Not because the feature was new. Because we finally understood who we were building for. The uncomfortable part: most organizations can't agree on who this is for. Sales wants everyone. Engineering wants power users. Leadership wants "the market." The workaround I learned is to pick one and be willing to disappoint the others. You cannot serve everyone and survive. Pick the human being who would miss this if it disappeared, build for them first, and let the rest catch up.

Practical check: Can you describe your primary user in a single sentence without using demographic labels? If your answer includes "millennials" or "tech-savvy professionals," you haven't gone deep enough. Try again.

2. What Problem It Actually Solves

There's a difference between the problem you think you're solving and the problem the user is actually trying to escape. I've seen teams spend eighteen months building solutions to problems that didn't exist, then pivot six months later to solve the real one with half the budget because the first attempt generated enough revenue to prove the concept. The mechanism I use is simple but rarely followed rigorously: before writing a single line of code or designing a single feature, I ask "what does the user do right now to deal with this?" If the answer is "they use spreadsheets" or "they ask their colleague Dave," you have a real problem. If the answer is "they don't have this problem," you need to go back to the drawing board. Spreadsheets are not a sign of failure. They're a sign that someone is already trying to solve this and accepting the friction. That's a market signal most people misread. I encountered an edge case with a scheduling tool where the problem wasn't that the software was slow. The problem was that the user's internal policy required manual approval for any meeting longer than two hours. No feature in the world would fix that. The workaround was to build a policy exception request workflow that integrated with their existing approval system. Revenue from that vertical tripled within a year. The product itself hadn't changed. We just stopped fighting the real constraint and worked with it.

The counter-intuitive insight here: sometimes the best product decision is to build less, not more. If you can solve the core problem with a narrower feature set and better alignment to the actual workflow, you'll ship faster, spend less, and often make more money. Breadth is a vanity metric. Depth is where margin lives.

3. Whether It Actually Works

This is the category most people screw up because they confuse "we tested it" with "it works." Testing is necessary. It is not sufficient. Something can pass all your acceptance criteria and still fail in production because the test environment doesn't reflect the chaos of real usage. I've seen load tests run at 2x expected traffic with zero issues, then crash on day one when a single enterprise client sent malformed requests that the parser couldn't handle. The standard I now apply is brutal: the product must work for the worst-case user in the worst-case condition, not the happy path. This means testing with slow connections, offline states, data entry errors, and users who click through screens in unexpected orders. It also means measuring actual outcomes, not just completion rates. Did the user accomplish their goal? Or did they just finish the flow? I had a situation with an e-commerce checkout where the conversion rate was 2.1% against an industry average of 3.4%. Every A/B test we ran improved the numbers marginally. Nothing moved the needle past 2.8%. Then we tracked what happened after submission. The problem wasn't the checkout. It was that the confirmation email had a broken tracking link, and 40% of customers never received it. Fixing the link took four hours and pushed conversion to 3.6%. The lesson: measure the entire journey, not just the piece you're proud of building.

Downside to acknowledge: rigorous working-tests catch problems early but they also create a false sense of security if your test conditions are too clean. The workaround is to periodically run chaos tests and invite real users into staged environments before anything ships. It's slower. It's worth it.

4. Whether It Sustains

This is the one that gets ignored until it's too late. A product can have perfect product-market fit, solve a genuine problem, and pass every working-test imaginable, then die six months later because the support costs exceeded the revenue, or the engineering team couldn't keep up with breaking changes in a dependency, or the original founder left and nobody understood the architecture. Sustainability isn't just about funding. It's about whether the organization building this thing can actually maintain it over a multi-year horizon. That includes documentation, onboarding processes, incident response plans, and the unglamorous reality of who will be answering tickets at 2am when something breaks. I've seen beautiful products killed not by competitors but by support burnout. The team literally couldn't keep up with the volume of questions from users who didn't understand how to use the thing that solved their problem. The practical framework I use: before launching anything significant, answer these questions in writing. What happens if three key people leave next month? Can someone new read the docs and understand the system in two weeks? Is there a clear escalation path when something breaks? What is the cost to serve per customer, and does the revenue cover it with room to grow? If you can't answer these honestly, you don't have a sustainable product. You have a prototype with commitment issues.

I learned this the hard way with a B2B analytics platform. We had 200 paying customers in eight months. Beautiful growth. Terrible unit economics. Every customer required six hours of onboarding because the documentation assumed familiarity with SQL and our data model was undocumented. Support tickets averaged 47 minutes each. We were losing money on every account. The fix was painful: we reduced our target deal size, forced self-serve onboarding, and shipped documentation that actually matched the product. Revenue per customer dropped 23% but profitability turned positive within two quarters. Sometimes sustainability means choosing to serve fewer people better, not more people poorly.

How These Four Interact

These aren't independent checkboxes. They compound. Get the first one wrong and the second one becomes impossible to define accurately. Get the second one wrong and the third one measures the wrong thing. Get the third one wrong and the fourth one is irrelevant because nothing worth sustaining exists. Get the fourth one wrong and you're running a charity with delusions of grandeur. The order that matters most in practice: start with who, then what problem, then whether it works, then whether it sustains. Not because this sequence is universally correct but because deviating from it usually means you've made an assumption you haven't validated yet. If you jump to "does it work" before you know who it's for, you'll optimize for the wrong people. If you skip to "will it sustain" before proving it works, you'll build infrastructure for a product that may not exist. I've seen teams reverse this order and call it "agile." It's not agile. It's gambling with better PR.

When These Four Aren't Enough

Seriously. There are contexts where even if you nail all four, the thing still fails. Market timing is one. Regulatory shifts are another. I watched a cybersecurity compliance tool that checked every box get rendered obsolete overnight when a new regulation changed the reporting format and rendered the entire product spec irrelevant. No amount of product-market fit or sustainability planning prevents a regulatory landmine. The alternative approach in those cases is to build for adaptability rather than optimization. Ship smaller, iterate faster, keep the architecture modular enough to pivot when the ground moves. This usually means accepting lower initial efficiency in exchange for higher long-term survivability. Most teams resist this because the metrics look worse in quarter one. They should resist less. Another limitation: the four-thing framework assumes you have the luxury of focusing on all four simultaneously. In practice, early-stage teams often have to sacrifice one to survive. Usually that's sustainability. That's fine for six months. It stops being fine at eighteen. Set a date when you pause growth to repair the foundation, and stick to it. I've watched too many founders treat "we'll get to it later" as a permanent strategy. It's not. Later always arrives.

What I Would Do Differently

If I could restart, I'd validate all four before writing any code. Not a landing page. Not a survey. A conversation with five real users about the problem, followed by a manual version of the solution delivered by hand to see if they'd actually pay for it. The cost is time. The cost of skipping this step is years. I spent three years building something that almost worked before I learned to do this upfront. The difference between those three years and the next three was whether I started with the four things or assumed them. The single biggest mistake I see organizations make is treating these four as a launch checklist. They're not. They're a continuous monitoring system. The who changes. The problem evolves. The working conditions shift. Sustainability requires maintenance, not just planning. Revisit all four quarterly, not annually. The market won't wait for your strategic planning cycle. That's the short version. The long version is whatever you make it based on how seriously you take the work in front of you.