Is your design agency on track? A week-four check for startup founders
Three to six weeks into a design agency engagement, a founder can still change course. This guide gives a scorecard, a checkpoint agenda and the levers for resetting or ending the work.
Illustrative situation: a seed-stage founder hires a product design agency to redesign the dispatcher dashboard of a logistics SaaS product. The engagement runs 12 weeks. At the end of week four, the founder has sat through four friendly weekly calls and seen a research summary, a journey map and a mood board. There are no screens yet. The founder skipped one review to close a customer deal, and the CTO has never opened the Figma file. Is this a normal start, or the first month of a slow failure? The founder cannot tell. The scene is invented.
Humbleteam publishes this guide and is a digital product design agency, so the scorecard below applies to our own engagements too. Choosing the agency comes first, and our guide to evaluating design agencies as a startup founder covers briefs, proposals and reference calls. The paperwork comes next, in our design agency contract checklist. This guide starts once the contract is signed, because evaluation does not stop there.
Why check at week four?
Early warning signs are easy to miss and cheap to act on. A 2011 paper on reviews of infrastructure and IT projects, presented at a PMI congress, found that project professionals are not very good at detecting them and even less good at acting on them. The authors found the signs matter most in the set-up phase. A later PMI conference paper, citing the project management author Harold Kerzner, says projects drift from green to yellow to red rather than failing overnight, and that the earlier the signs are found, the more recovery options remain. Those options are minor changes, major changes, or ending the project.
Timing also protects your judgment. In their study of the sunk cost effect, Hal Arkes and Catherine Blumer found that people who had already invested in a project rated its chances of success higher than people judging the same project without that investment. On a 12-week engagement, week four falls after the first full cycle of work and before most of the budget is spent. That timing is our suggestion, and a six-week engagement would check at the end of week two.
What should a healthy engagement show by weeks two, four and six?
Basecamp’s Shape Up method pictures every piece of work as a hill. On the way up, the team works out what to do. On the way down, it executes. Shape Up’s advice to anyone watching from outside is that a piece of work stuck in one place is “effectively a raised hand”, because people rarely say “I don’t know” out loud. Watch whether the work moves, not how busy everyone looks.
UK government guidance for reviewing agile digital projects makes a similar point: the primary way to evidence progress is “showing the thing”. It tells reviewers to check whether demos are open about challenges and unfinished work. Nielsen Norman Group gives the practical reason to see design early: engineers can question technical feasibility while the designs can still change without wasting time and money.
A proposed timeline for a 12-week engagement, to adjust to yours:
- By week two, the team named in the proposal has shown up and has access to your analytics, support tickets and design files. The agency has restated the problem in its own words, and you agree with the wording. One person on your side is named as the decision owner.
- By week four, some evidence exists, such as customer sessions, analytics findings or patterns in support tickets. Decisions are written down with their reasons. Rough screens of the riskiest flow have been shown, and an engineer has commented on them.
- By week six, the riskiest flow has been checked with users or reviewed against the evidence. The list of open questions is shorter than at week four, and the new questions concern detail, not direction.
Which signals predict trouble, and which only confirm it?
The first PMI paper notes that traditional project measures are lagging indicators, the consequences of what has already happened. Early warning signs are leading indicators that point to what is coming. In design work, a missed deadline, an overspent budget and a final file you dislike are all lagging signals. By the time they appear, most of your options are gone.
Leading signals show up in week-to-week behavior. A decision waits for days. The agency presents slides about the work instead of the work. The list of open questions stays the same length. A new designer appears on calls without notice. Each round of feedback is bigger than the last. The Kerzner list in the second PMI paper shows the same patterns in general projects: different opinions on the project’s purpose, delayed decisions that lead to missed deadlines, and poor change control.
Is the problem on the agency’s side or yours?
Often both, and the founder’s side is the one people overlook. PMI’s 2018 Pulse of the Profession survey asked 4,455 project management practitioners about the primary causes of their failed projects. The three most common answers were a change in the organization’s priorities (39%), a change in project objectives (37%) and inaccurate requirements gathering (35%). The survey covers projects of every kind, not design engagements. Still, all three causes belong to whoever owns the brief, and in a startup that is usually the founder.
The design profession’s reference contract makes the same point from the agency side. The AIGA Standard Form of Agreement for Design Services says the designer’s ability to meet schedules is “entirely dependent” on the client providing materials and approvals promptly. It makes the client responsible for coordinating decisions with anyone other than the designer, such as a co-founder or an investor. Its notes warn designers that first-time clients often do not realize how much information, content, scheduling, decision-making and approval the work will need from them.
Four founder-side causes come up again and again: slow feedback, a brief that keeps moving, no single decision owner, and access that never arrives. Before the checkpoint, count your own numbers. How many days did your replies take? How many times did the goal change? Which logins are still pending? If the agency’s problems trace back to these, a new agency will inherit them.
How do you run the checkpoint conversation?
Run it as a review with an agenda, borrowing from Atlassian’s Team Health Monitor. Each person rates each attribute green, yellow or red, and everyone votes at the same time to avoid groupthink. If a team tends to call things “okay” when they are not, Atlassian suggests starting every rating at red and making the team argue its way to green. The session opens with the retrospective prime directive: everyone did the best job they could with what they knew at the time.
Nielsen Norman Group’s guidance on design critique adds two rules. Agree on the objective first, because without one any feedback is subjective. And keep it a conversation, because directives shut the discussion down.
A proposed 60-minute agenda:
- Send the scorecard below two days ahead. You and the agency lead each fill it in separately.
- Compare the ratings. Skip the rows where you both chose green.
- Discuss each red, one at a time. Talk about the work, not the person. Shape Up’s question works well here: what is the unknown holding this back?
- Agree on no more than three actions, each with an owner and a date.
- Set the next checkpoint and write down what green will mean by then.
The week-four scorecard
Rate each row green, yellow or red. Do not add up the colors, because a decent total can hide the one red row that decides the project. The “usually whose side” column is our judgment, so check it against what happened.
| Signal | Healthy by week four | Warning sign | Usually whose side | Question to ask |
|---|---|---|---|---|
| Decision owner | One named person on your side makes the final call on scope | Two founders, or a founder and an investor, give conflicting feedback | Founder | Who has the final say on this, and does everyone know it? |
| Problem statement | The agency restated the problem and you agreed with the wording | The goal changed after kickoff, or each call reopens it | Founder, sometimes shared | Has the goal changed since kickoff, and was the change written down? |
| Feedback turnaround | Comments arrive within the agreed window, in one combined round | Replies take a week, or arrive in pieces from several people | Founder | How long did our last three replies take? |
| Access and materials | Analytics, support tickets, files and customer contacts handed over in week one | Logins still pending, customer calls not scheduled | Founder | What are you still waiting for from us? |
| Named team | The people named in the proposal attend and do the work | New faces without notice, lead designer rarely present | Agency | Who worked on this week’s output, and for how many days? |
| Work shown | Rough screens or flows of the riskiest part, in the design file | Only decks, summaries and mood boards | Agency | Can we see the current file, unfinished parts included? |
| Evidence | Findings from customers, analytics or tickets, each tied to a design choice | Research still “in progress” with no findings, or findings that changed nothing | Agency | Which finding changed the design, and how? |
| Decisions logged | A written log of what was decided, why and by whom | Decisions live in call memory and get reopened | Shared | Where is last week’s decision written down? |
| Engineering involved | An engineer has commented on the screens and flagged constraints | Engineers have not seen the work | Shared | What did engineering say about the hardest screen? |
| Open questions | The list is shorter than at week two, and what remains is detail | The same questions have stayed open for weeks | Agency, sometimes founder | What is the unknown holding this back, and who can answer it? |
| Scope and changes | Changes get a written estimate before work starts | Requests slip in by chat, and scope grows with no price attached | Shared | What has been added since kickoff, and what did it cost? |
| Budget against progress | Spend roughly matches the share of work done (our rule of thumb) | A third of the budget gone and nothing a user could react to | Agency, or founder if your delays caused it | What share of the budget is spent, and what share of the work is finished? |
An illustrative checkpoint, worked through
This continues the invented logistics scenario, with no real agency or figures. The founder and the agency lead fill in the scorecard separately before the week-four meeting. Six rows needed discussion.
| Signal | Founder’s rating | Agency lead’s rating | Agreed action and owner |
|---|---|---|---|
| Decision owner | Green | Red: two people send conflicting comments | The founder keeps the final say on scope and names the CTO as final say on technical constraints. Owner: founder, this week |
| Feedback turnaround | Yellow | Red: comments took about six days on average | The founder books two 45-minute review slots a week. Owner: founder |
| Work shown | Red: no screens | Yellow: research had to come first | Rough screens of the dispatch board by next Friday. Owner: agency lead |
| Engineering involved | Red | Red | The CTO comments in the file before each review. Owner: CTO |
| Named team | Red: lead designer joined one call in four | Yellow | Lead designer back at the agreed share of time, confirmed in writing. Owner: agency |
| Scope and changes | Yellow | Yellow | The reporting module moves out of this phase and gets its own estimate later. Owner: both |
Of the five rows with a red, two traced back to the founder, and only the agency lead had marked them red. Without separate ratings, the founder would probably have blamed the agency for those too. Two sat with the agency, and one was shared. The meeting ends with a stop point for week six: the CTO and at least two dispatchers have reviewed the dispatch board screens, and the lead designer has attended every review in between. If both hold, the work continues. If the agency’s items fail, the founder ends the engagement at week six and keeps the work paid for so far.
What does a recovery plan look like?
The three options from the PMI paper become three levers.
The first is to reset the scope. Cut back to the riskiest flow, finish it, and move the rest to a later phase with its own estimate. A smaller scope also tests whether the brief was the real problem.
The second is to change the team. If the senior people from the pitch have disappeared, ask for them back at the agreed share of time, or for a different lead. The named-team clause in your contract is the reference point.
The third is to add a stop point. Write down a date, two or three criteria anyone can check, and what happens if the criteria are missed by then. Agree on it with the agency in writing. A stop point turns a vague worry into a decision you have already made.
When should you end it, and how?
End it when the agency-side reds persist after a reset in which you kept your side of the deal, or when a stop point passes with its criteria missed. Decide against the criteria you wrote down beforehand. The sunk cost research explains why: by week eight you will have more invested and will likely rate the project’s chances higher than the evidence supports.
End it cleanly. Give written notice in the form your contract requires, and name the criteria that were missed. Ask for the source files, work in progress, research notes and decision log for everything you have paid for. Our guide to running an external UX team inside your sprints lists a full handover pack, and the contract checklist covers the termination and ownership clauses to read before you send notice. Pay what you owe for work done, so the handover is not held up by a dispute.
What can you produce now?
Three documents before your next agency call. First, your own scorecard, with every row filled in, including the ones that point at you. Second, a request to the agency lead to fill in the same sheet separately. Third, a draft recovery note with up to three actions and their owners, the next checkpoint date, and the stop-point criteria you would accept. If the checkpoint goes well, the note becomes your plan for the next three weeks. If it does not, it is the record you end on.
