A lot of product writing still assumes the best lessons come from scale, funding, and well-resourced teams.

I do not think that is true.

Some of the most useful product lessons I have learned came from building where there was very little room for error: tight budgets, moving deadlines, manual processes everywhere, and consequences that appeared quickly when the sequence was wrong.

That was the environment in which I worked on a university management platform in Nigeria.

This was not a product where a missed priority meant a slightly weaker quarter or a delayed feature. If admissions were not handled on time, students could lose their place. If fee collection was not tightly designed, revenue slipped through the cracks. If reporting was bolted on later, leadership was left making decisions with partial visibility.

And when COVID disrupted in-person operations, the real test was not whether the platform was elegant. It was whether it could stretch fast enough to keep the institution going.

That experience led to the CAPE model: Crisis-first prioritisation, Architecture as incentive, Parallel data infrastructure, and Extensibility by design.

It is not a universal method or a perfect formula. CAPE is a practical approach for teams working under pressure, where making decisions in the right order matters more than having a perfect plan.

C – Crisis-First Prioritisation

Most teams claim to prioritise based on value and effort, which works to a certain extent. But that logic starts to break when one unresolved failure can make everything else irrelevant.

That was the reality with admissions.

Back then, onboarding new students was mostly manual. Students had to go through admissions and registration using paper forms, scattered checks, and staff help at nearly every stage. Some travelled far, and many faced tight deadlines. If the system could not handle the pressure, students were left out. So onboarding came first.

Not because it was the most innovative part of the platform. Not because it looked best on a roadmap. But because it was the point of maximum failure. If that process broke, the rest of the platform did not matter.

This is the first CAPE principle: do not begin with the biggest opportunity. Start with the failure that would cause the most harm if not fixed right away.

This sounds simple. It rarely feels simple when you are in it. Teams are often tempted to spread effort across multiple visible needs, especially when stakeholders are pulling in different directions. But under constraint, spreading attention can become a disguised form of avoidance. It feels balanced. It usually weakens delivery.

Constraint forced a more uncomfortable question: if we solve only one thing properly first, what must it be?

That question still matters in better-funded environments. The teams that answer it honestly tend to build stronger first releases. The ones that do not usually end up with wider roadmaps and softer foundations.

If the first release does not stabilise the highest-cost failure, it is probably the wrong first release.

A – Architecture as Incentive

One of the university’s most persistent problems was fee non-compliance, which was a major design flaw.

Instead of treating payment as an administrative task sitting beside the academic journey, we made it structural. Payment unlocked registration. Registration unlocked examination eligibility. No payment, no progression.

Simple. But load-bearing.

That decision changed the logic of the platform. Focus shifted from prompting people to comply to system logic flow. That distinction matters more than many teams realise.

A lot of product decisions around behaviour are still handled as messaging problems. But where the behaviour is business-critical, architecture usually does more than persuasion ever will.

That is what I mean by architecture as incentive. Design the system so that the right behaviour is built into the sequence.

Fee compliance improved significantly once that dependency was built into the platform. But the bigger lesson was that if a product depends on a certain behaviour, the architecture should carry some of that burden.

Where behaviour matters, remove optionality before you add reminders.

P – Parallel Data Infrastructure

This is where many products let leadership down. The workflow functions, users complete their tasks, and transactions go through. But the institution still cannot see what is really happening.

That was the situation here. Stakeholders did not have a unified view of the entire process.

Under delivery pressure, it is easy to ship the workflow first and push reporting to later. It feels efficient. It is not. The blind spots it creates cost more than the time it saved.

So we built reporting alongside the workflows.

That changed decision-making. Leadership could see revenue position more clearly. They could see registrations by programme and level. They could see where payment and enrolment patterns were shifting before those shifts hardened into operational problems.

This is the third CAPE principle: if a workflow matters operationally, it should matter analytically at the same time.

A product that cannot be observed properly while it is running creates a second-order risk. Decisions start being made through lagging assumptions rather than current evidence. Then teams spend months compensating for visibility they should have designed in from the beginning.

A workflow without instrumentation is operationally live but strategically blind.

Build the workflow and the visibility model together. Do not ask leadership to steer blind and promise the dashboard later.

E – Extensibility by Design

As time elapsed, we continued to build the platform with robust functionality to the point where it was set up to handle key university tasks such as admissions, fee payments, registration, exams and transcripts.

Then COVID happened.

Almost overnight, everything changed. Concerns about registration, exams, fees, and related processes became secondary, because if students were not learning, then they had no need for these functionalities. Our focus shifted to whether the platform could adapt fast enough to keep things running when in-person classes and operations stopped.

The platform supported admissions, fee payments, exams, and transcripts, but there was no learning capability. That gap became our focal point. The question was immediate: build learning capability from scratch, or integrate an LMS fast enough to keep the university running?

Students were at home. Teaching had stalled. Revenue had dropped. The institution did not need the perfect answer. It needed the fastest viable one.

We chose integration because of an earlier architectural choice: we had built with enough modularity to absorb new capability without rebuilding everything. Not infinite flexibility. Just enough openness to make the next move possible.

That is what extensibility means in practice.

It does not mean building for every possible future; that leads to overengineering. Extensibility by design is about leaving enough room for the next real change, without having to rebuild the core each time things change.

This matters because product teams often treat extensibility as optional until the day it becomes urgent. By then, it is expensive.

The LMS integration was delivered in four months. Academic continuity resumed. Revenue recovered materially within the same cycle. But the bigger lesson was architectural: the systems that survive external shocks are not always the ones that predicted them. They are the ones that were not built too rigidly to respond.

Build for the next real challenge, not every possible scenario.

CAPE is not valuable because it sounds neat. It is valuable because the sequence holds.

Every fast-growing product hits its own version of admissions: one failure point that sinks the roadmap if it is not solved first, and everything after is negotiable by comparison. Every product with a revenue-critical behaviour hits its own version of the payment gate: something the business depends on that either gets built into the architecture or gets chased forever with reminders.

Every team hits its own version of the reporting problem: leadership flying blind because visibility got postponed in favour of shipping the workflow. And every product eventually meets its own COVID: the shock nobody planned for, which tests whether what you built can bend or whether it breaks.

That is why CAPE transfers. Constraint is not really about budget. It is about the ratio between what needs to be true and what you can afford to get wrong. That ratio shows up under a tight funding round, a hard regulatory deadline, a lean internal tools team, or a startup running on six months of runway. Different pressure. Same discipline required.

If I am honest, the hardest principle to actually apply is Architecture as Incentive. Crisis-first prioritisation is a decision you make once, at the start. Extensibility is a habit you can build into your standards over time. Architecture as incentive asks for something harder: enough conviction to make a behaviour non-negotiable in the product itself, instead of solving it downstream with a nudge or a campaign.

That is a difficult conversation to have with stakeholders who find it easier to ask users nicely than to remove their options. It is also the principle most likely to get diluted in a design review, because “let’s just add a reminder” always sounds like the more comfortable choice. It rarely is the right one.

If you are already building lean, in Lagos, in West Africa, in a market where “we did not have the budget to do it differently” is not a talking point but a Tuesday, I am not telling you that constraint is good for you. You already know that.

What I am arguing is narrower, and I think more useful. Constraint by itself does not produce discipline. It produces pressure. What you do with that pressure is a separate question, and it is entirely possible to build under real constraint and still get the sequence wrong, because most of the advice available to lean teams was not written for lean teams. It was written by people with a cushion, for people with a cushion.

“Ship fast, add compliance later” is not bad advice. It is advice for someone who can afford what later costs. Defer the same decision with no funding round waiting behind it, and later usually means never, or it means an emergency that costs ten times what the decision would have cost the first time.

Every deferred decision in this piece — treating payment as optional, building reporting later, skipping the modularity needed for extensibility — is exactly this kind of borrowed advice. It sounds efficient right up until there is no later budget waiting to absorb what the deferral cost.

CAPE is my attempt to name, deliberately, what most of us learn by accident under deadline pressure. Not a claim that constraint builds character. A way to check, before you ship, whether you have quietly borrowed a sequencing decision that only makes sense for somebody else’s balance sheet.

That discipline is worth keeping even after the constraint eases. Most of us are not trying to escape constraint so we can finally stop thinking this way. If the funding shows up, the goal is not to lose the instincts that got you here.

Read also: FUTA honours alumnus-turned-cybersecurity-entrepreneur as university hosts landmark international computing conference