Firstclub
Product Design Manager · founding team
[TO VERIFY] dates
Making the team better instead of doing the work myself
One designer, one hard problem, and what changed because you were their manager rather than a second pair of hands.
- Role
- Product Design Manager — coaching, not executing
- The designer
- [TO VERIFY] their level and scope
- The problem
- [TO VERIFY] one line
- Timeline
- [TO VERIFY] dates
- Outcome
- [TO VERIFY] what changed for them, and for the product
Why this is the most valuable page on the site
- This is the one story a senior individual contributor cannot tell. It is your clearest evidence of leverage.
- The rule throughout: show what the designer did, and show what you asked. Never write “I told them to…” — write the question you put to them.
- Name them and credit them. It makes you look more senior, not less.
The problem the designer was handed
Answer these
- What was the brief, and from whom?
- How experienced were they, and what were they already good at?
- Why was this a stretch for them?
Their first approach
Show it fairly — the story only works if their start is credible.
Answer these
- Where did they start — UI, flow, a competitor pattern, a prototype?
- What was genuinely good about it?
- Send a screenshot or flow sketch of the early work if you have one.
What I noticed
Answer these
- Were they solving the stated problem rather than the real one?
- Were they optimising for the wrong thing — discoverability over simplicity, novelty over habit, speed over reassurance?
- Had they accepted a constraint that was actually negotiable?
How I coached them
The questions, not the instructions.
Write the actual questions you asked
- “What decision is the user trying to make here?”
- “Where do they get stuck, and what happens right after?”
- “What would have to be true for this to be the right answer?”
- Replace those with yours. Then: how much room did you give them before stepping in, and what did you resist fixing yourself?
How the work evolved
Before and after — of their thinking, not just their pixels.
Three before/afters, ideally
- Problem framing: before → after
- The flow: before → after
- The design: before → after
- Send me the screens and I'll lay these out as labelled pairs, the same way the Cleartrip iterations are built.
My role
Even a coaching story needs the ownership split stated.
-
Owned
[TO VERIFY] — problem framing? product direction? a specific flow you designed yourself?
What you directly owned and executed. -
Co-owned
with which PM or designer, and on what exactly?
Jointly owned with someone else. -
Influenced
what did you change someone's mind about, and what did they think before?
You materially changed the direction without executing everything. -
Enabled
name the designer, what they owned, and what you supplied — context, critique, a constraint removed?
A team member executed it; you gave direction and support. -
Team outcome
what should be credited to the team rather than to you?
The result belongs to the wider team.
What changed for the designer
The outcome that matters on this page.
Answer these
- What can they now do without you?
- Did they take on a bigger scope, present to leadership, mentor someone else?
- Did the reasoning stick — did you see them apply it unprompted on the next problem?
What the product got
Any evidence you have
- A metric, a launch, fewer iterations, a cleaner solution than the original direction.
- One line is enough. The point of this page is the coaching.
Reflection
One honest paragraph
- Did you step in too early or too late?
- What would you hand over sooner next time?
Evidence standard — from your knowledge base, §21
- Verified — explicitly stated in your source material. Safe to publish.
- Strongly supported — derivable from several source statements. Safe to publish.
- Inferred — a reasonable reading, not stated. Use as a prompt for you to confirm, never as copy.
- To verify — missing. This is what the dashed blue text on this page is.
- Portfolio copy uses only the first two. I have written nothing above that standard.