Portfolio technical triage for startup cohorts in 2 weeks

Why the first two weeks get messy

A cohort never arrives in neat order. One startup has two founders and a rough prototype. Another has 15 people, paying customers, old code, and a roadmap nobody fully trusts. If you review both with the same depth, you waste time where it matters most.

Founders also start with the clean version. That's normal. They know the pitch, the product story, and the plan they want others to believe. The harder job is seeing how work actually happens day to day. A team may say shipping is on track while release dates keep slipping. They may say AI is on the roadmap, but have no usable data, no owner, and no real reason to add it.

The time limit makes bad choices expensive. Long audits sound careful, but they burn the window before you can decide where support should go. If every startup gets a deep review, you can spend most of the first two weeks collecting details and still miss the urgent problems. Help then goes to the loudest founders, not the startups with the most risk.

Fast triage fixes that. It does not answer every question. It sorts the cohort into simple groups: problems that need action now, problems that can wait a month, and issues that matter only after the product proves demand.

A small example makes the point. Startup A has a rough product, but users love it and the team ships every week. Startup B looks polished in a demo, yet nobody can explain how work gets done or who owns the next release. Startup C wants AI features, but customer data lives in spreadsheets and inboxes. Those teams should not get the same help first.

What to collect before you talk to founders

For cohort triage, the intake pack matters more than a long intro call. Ask every startup for the same small set of materials. You'll save time, spot gaps quickly, and avoid judging one team on a polished story and another on a rough first meeting.

Start with the basics they already have: the latest deck or company summary, a current product demo even if it's rough, the roadmap for the next few months, and a team list that shows who owns product, engineering, and go-to-market.

Then ask for one short written note with three numbers or estimates: users, revenue, and runway. It doesn't need to be perfect. You're checking whether the founders know their operating reality and whether the product story matches the business picture.

Delivery evidence helps even more. Ask for a simple view of recent releases, the current backlog, and who owns each area. A screenshot from their tracker, a short export, or a plain text note is enough. If a team says it ships often but can't show what shipped in the last month, slow down and verify.

Use one intake form for every startup. Keep it short enough to finish in 20 to 30 minutes. Good forms make comparison easier because every founder answers the same questions in the same format.

If a startup struggles to send these basics after a clear request, that's a signal too. Sometimes the issue is plain chaos. Sometimes it means the team has not turned plans into working habits yet. Either way, you learn something before the first call starts.

Set one scorecard for the whole cohort

If each startup gets judged through a different lens, the ranking turns into opinion. A shared scorecard makes triage faster, fairer, and easier to defend when founders ask why one team sits above another.

Keep the scale simple. Score product risk, delivery risk, and AI readiness from 1 to 5, and keep the direction consistent. In most cases, 1 should mean low risk or ready now, while 5 should mean high risk or not ready.

Write the score meanings before the first founder call. That small step stops score drift.

• 1 means the team has clear evidence, steady execution, and few open questions.
• 3 means the picture is mixed. Some proof exists, but gaps could slow progress.
• 5 means the team has major unknowns, weak proof, or obvious blockers.

Use the same logic for AI readiness. A 1 might mean the startup has usable data, a real workflow worth improving, and someone who can own the work. A 5 might mean the team talks about AI in broad terms but has no clean data, no process, and no real use case.

Add one more field: confidence. Mark each score as high, medium, or low confidence. If a founder gives strong answers but shows no usage data, the score may be reasonable, but confidence is low. That matters later when you compare teams.

Leave room for two short lines under each category: one note on what drove the score and one next action to reduce uncertainty. That keeps triage practical. You can scan ten startups and see the pattern quickly. It also makes it easier for a fractional CTO or advisor to see where a short technical audit, product check, or AI workflow review would change the ranking.

Run a 60-minute review for each startup

An hour is enough if you keep the call tight and move past demos quickly. Most founders can fill 60 minutes with features. A good review keeps returning to risk, speed, and what blocks the business right now.

Use the same clock for every company. That keeps the review fair and stops louder founders from taking more airtime than quieter ones.

• 0 to 10 minutes: Ask the founder to explain the company in plain language. What problem do they solve, for whom, and why does it matter now? If they need jargon to explain it, that is already a signal.
• 10 to 25 minutes: Move to product, users, and traction. Ask what customers use most, what they ignore, how many active users they have, and what changed in the last 90 days.
• 25 to 45 minutes: Shift to delivery. Who builds what, how decisions get made, what is on the roadmap, and how work ships today? Ask how often they release, where work gets stuck, and who can unblock it.
• 45 to 60 minutes: Finish with AI use, data access, and the next blocker. Ask what they already automate, what data they can actually use, and what stops them from moving faster this month.

One rule helps: ask for one concrete example in each block. If a founder says shipping is slow, ask what the last release was and why it slipped. If they say AI is part of the plan, ask what task they want AI to handle first and whether they have clean data for it.

Don't let the meeting drift into architecture debates. This is triage, not a deep audit. By the end of the hour, you should be able to say where the risk sits, how urgent it is, and what single next step would reduce it.

Spot product risk early

Product risk shows up before the build breaks. It usually starts when a startup cannot explain, in one sentence, what problem it solves and who pays to solve it. If the answer keeps changing, risk is already high.

Ask for one clear buyer and one clear pain point. "Small businesses" is too broad. "Clinic managers who waste hours chasing missing patient forms" is easier to test, sell, and improve.

Then compare the roadmap with what users ask for now. This part is often uncomfortable. Founders may have a long feature list, while users want something much simpler, like fewer steps, better reporting, or faster setup. When planned work and real demand move in different directions, the product can drift for months.

Weak proof is another warning sign. A smooth demo doesn't mean the product matters in daily work. Look for signs that people return on their own and use the product for a repeat task.

A few questions help. How often do active users come back each week or month? Which feature do people use more than once? What did users do before this product existed? What would annoy customers if the product disappeared tomorrow?

That last question matters a lot. Teams with real traction usually answer quickly and with detail. Teams with weak proof often fall back on vague praise or talk about future plans.

Watch retention closely. If the team can't explain why people stay, they don't understand their own pull yet. A startup with 500 signups and thin repeat use is often riskier than one with 25 loyal customers who depend on the product every Monday morning.

Spot delivery risk early

Delivery risk lives in the gap between plans and shipped work. A team may sound organized on a call, but the real test is simple: how often do they release, how much breaks after release, and how quickly do they fix it?

Start with recent history, not the roadmap. Ask what shipped in the last 30 days, how many releases went out, and what happened the last time a bug hit users. Clear answers usually mean the team tracks real work. Vague answers usually mean the team works from memory and guesswork.

Ownership matters just as much. Someone should know who makes architecture calls, who pushes releases, and who takes charge when production issues appear. Shared ownership can work. Fuzzy ownership usually creates delays and blame.

Trouble tends to show up in familiar ways: releases happen only when one senior engineer is around, bugs stay open because nobody sets priority, product and engineering wait on each other for days, the backlog exists but nobody trusts it, or founders keep changing priorities mid-sprint.

One warning sign deserves extra weight. If one person holds most of the technical context, delivery slows the moment that person gets busy, sick, or leaves.

A simple example makes this clear. Imagine a startup with six engineers that says it ships every week. When you ask what shipped last week, the team mentions one hotfix, two delayed features, and a rollback nobody documented. The CTO approves every merge, one backend engineer handles all production alerts, and the backlog still contains tasks from four months ago. That team doesn't have a speed problem first. It has a coordination problem.

Mark delivery risk higher when work depends on heroics. Healthy teams don't need perfect process. They need clear owners, trusted priorities, and a steady habit of shipping and fixing.

Judge AI readiness without guessing

Teams often say they are ready for AI when they really mean they don't want to fall behind. That isn't enough. AI readiness should rest on a simple test: can the startup name a business problem, the workflow around it, and the person who will own the work?

Start with the boring questions. They tell you more than any demo. Where could AI cut cost, save time, or improve output in a way the team can measure? What data does the startup already have, and can the team actually use it? Is there a repeatable workflow, or does every case get handled differently? Who will run the test, review the results, and make changes after week one?

A real use case sounds specific. "Sort support tickets before a human sees them" is real. "Draft follow-up notes from sales calls" is real. "Add a chatbot" usually isn't. If the founder can't explain what the bot should do, what data it needs, and how success will look, score the idea lower.

Data is where many teams fail. If customer records are spread across email, spreadsheets, and random notes, the startup may still have a good AI idea, but it isn't ready to build much yet. The same goes for weak process. If nobody follows the same steps twice, AI has nothing stable to plug into.

A small example helps. One startup wants an AI assistant for support. It has tagged tickets, response history, and a support lead who owns the process. That team is fairly ready. Another startup wants "AI for growth" but has no clean data, no repeatable workflow, and no owner. Score that one low and move on.

A simple cohort example

Picture a batch of three startups in week one. They all look busy, and they all sound urgent. A simple scorecard makes the differences obvious.

Startup A already has demand. Prospects turn into trials, customers ask for features, and the team has proof that the market cares. The trouble is delivery. One engineer handles product work, bug fixes, and infrastructure, so releases keep slipping. Small changes wait too long. This company doesn't need a big strategy session first. It needs delivery help now: cut scope, shorten release steps, and protect the engineer from constant interruptions.

Startup B has the opposite problem. The team ships often, but users still describe the pain in different ways and retention stays weak. Fast output can hide a fuzzy product problem. If the team keeps building without sharper feedback, it may waste the next six weeks. This startup needs product help first: better interviews, one clear user problem, and a tighter test of what makes people come back.

Startup C gives you the clearest AI case. Support logs show the same questions every day. Staff repeat the same work to sort tickets, summarize calls, and draft replies. That is a practical setup for automation. The team already has real data, repeated tasks, and an easy way to judge results. You don't need to guess whether an AI pilot has a use case. The use case is already there.

How the ranking changes

Once you score all three the same way, the order gets simpler.

• Startup B gets product help first because more shipping won't fix weak demand.
• Startup A gets delivery help next because customer pull is real, but releases are late.
• Startup C gets an AI pilot first because the work is repetitive and easy to measure.

That is what triage should do. It should tell you where founder time helps most this month.

Mistakes that slow the review

The loudest founder in the room often gets the benefit of the doubt. They answer fast, sound certain, and can pull the whole conversation toward their version of the score. That's a bad way to run triage.

A calm founder with weak delivery may sound less impressive than a strong storyteller with a shaky product. If personality drives the session, you stop measuring risk and start rewarding confidence.

Another common mistake is going deep on architecture before you confirm the business problem. A team may talk about agents, vector databases, or complex workflows, but none of that matters if the customer problem is still fuzzy. Ask who the user is, what hurts today, and what proof exists that anyone wants the fix. Then talk about the technical side.

Teams also lose time when they mix current risk with long-term potential. These are different things. A startup can have a smart team, a big market, and real upside, while still being risky right now because the roadmap is vague or the product breaks in basic use. Score today's condition first. Keep future upside in a separate note.

AI creates its own trap. Founder interest in AI is cheap. AI readiness is not. A team isn't ready because it wants a chatbot, plans to add copilots, or says automation will cut costs.

Real readiness looks more ordinary: clear internal workflows, usable data, someone who owns the rollout, a way to test output quality, and a product area where AI solves an actual bottleneck. If those pieces are missing, mark it as interest, not readiness. That distinction saves hours across a cohort review and keeps the ranking honest.

Quick checks before you rank the cohort

Ranking too early creates false confidence. A startup can sound polished in a founder call and still hide weak delivery habits, unclear product proof, or no real path to AI use.

Use the same final checks for every company. That keeps triage fair and makes the ranking easier to defend when partners or mentors ask why one team moved up and another moved down.

Keep the checklist short. Confirm that every startup completed the same intake and got the same meeting length. If one team had a detailed pre-read and another got a rushed call, the scores aren't comparable. Make sure each score points to evidence. A strong product score needs proof such as user interviews, retention data, active pilots, or a clear buying signal. A weak delivery score should tie to facts like missed releases, no owner for major work, or poor testing habits.

Write one urgent action for each startup and keep it specific. "Talk to five users this week" is useful. "Improve product strategy" isn't. Also separate cohort-wide patterns from one-company issues. If six teams lack basic analytics, that's a cohort gap. If one team has a risky founder conflict, keep that in its own file.

That last step matters more than people think. Cohort-wide patterns shape workshops, mentor matching, and shared support. Company-specific problems shape follow-up with that founder only.

A simple test helps. Hand your notes to someone else and ask, "Could you explain this rank from the evidence alone?" If they can't, tighten the scorecard, cut vague comments, and replace opinion with proof. That takes an extra hour, but it saves days of debate later.

What to do after triage

Once the scorecards are done, sort each startup by urgency, not by pitch quality. Good triage should end with a short action queue that investors, program leads, and founders can all use.

Three groups usually work well:

• Act now: the startup has a clear risk that can hurt revenue, delivery, or trust in the next 30 to 60 days.
• Watch closely: the team can keep moving, but one weak area needs proof soon.
• Revisit later: the startup has open questions, but no immediate threat blocks normal progress.

This ranking keeps the cohort from treating every problem as a fire. It also helps founders see that triage is about sequence. They don't need to fix everything this month.

Send each founder short notes right after the review. Keep them plain and specific: what you saw, why it matters, and what they should fix first. Two or three points are enough if they are concrete. "Backlog too big" is vague. "One engineer owns deployment, releases slip every week, add a second owner this sprint" is useful.

Then choose one small test for each startup where the evidence supports it. If delivery risk is the main issue, run a small process experiment such as weekly release targets, bug triage twice a week, or one shared roadmap. If AI readiness looks real, pick a narrow use case with a clear output, such as support draft replies, code review checks, or internal search over product docs. Don't approve a broad AI plan just because the team sounds excited.

A simple rule helps here: one startup, one next experiment, one owner, one date to review results. That keeps the cohort moving.

Some cohorts need outside help after the first pass. If several startups show the same pattern, such as weak architecture choices, slow delivery, or unclear AI plans, Oleg Sotnikov at oleg.is can review the findings as a fractional CTO and help founders turn them into a realistic plan. That kind of support works best when the notes are short, ranked, and tied to evidence.

If you finish triage with a clean ranking and a small next step for each team, the cohort can move fast without guessing.