How I'd Approach This
The Situation
Enterprise users are asking for custom requests. The Solutions team is building custom scripts for them. For models that are hosted directly with customers, we can't see how they're using them or how it's going.
This isn't scalable. It's also lost value if it only serves one user, when maybe more companies want this.
The Opportunity
Turn this into a design programme and see if it could scale into something for more customers. We already have one case study.
My Approach
1. Set criteria early
We can't waste too much time on each of these cases. There are many of them. We need to test quickly and see which ones stick. So we set criteria early on what success looks like, and have guidelines worked out with Finance so we're not working from first principles every time.
2. Align before starting
Have a sync meeting to define: what is the design product, what kinds of users it might suit, what features we need to test, what segments we need to test on, and how many users we'd need to see interested for this to be worth our time. Then set the DRIs and team responsible.
3. Recruit the right users
Don't over-incentivise. We need to test that they actually want the product. Search our database proactively for users who'd be a good fit. Publicise to Sales for prospects they couldn't close but who might need this feature.
4. Create visibility where we don't have it
For users with open weight models hosted locally, we can't see usage. So we ask if they can share logs for the duration of the programme. Set up a Slack channel for each customer. Track behaviour where we can.
5. Make it easy to run
There should be a playbook and checklist for every design project, so it's easier to do each time. Document the onboarding process, automate as much as possible. Have a comms playbook. Set up dashboards from day one.
6. Keep partners engaged without annoying them
These users are hard to recruit, so they need white glove service. We need to show we're bringing value. Personal check-ins on Slack, not over-emailing. Office hours for questions.
7. Decide with evidence
At the end of the set time, if we see no traction or they don't want the features, check in with customers and get honest feedback on whether it's right to drop this. If we see real traction, bring the data to the table.
8. Transition properly
If it works, transition to a beta programme and follow a beta-to-launch playbook to polish the product for general access.
Why This Approach
The point is to take the thinking out of setting up the process so the team can focus on the features of the new product. Every design programme has the same bones: recruitment, onboarding, engagement, evaluation. Playbooks and templates mean we're not reinventing the wheel each time.
Be intentional and mindful. Don't waste time and effort, but also don't miss where value is hiding.
Core Principles
1
Be intentional, not reactive. Decide upfront what success looks like.
2
Test demand, don't assume it. One customer asking doesn't mean it's a product.
3
Move fast, but know when to stop. Killing something that isn't working is a success.
4
Standardise the repeatable. Playbooks do the heavy lifting.
5
Treat design partners like gold. White glove service gets honest feedback.
6
Automate where possible. Use AI to scrape feedback, update FAQs, and reduce manual work.
This framework exists to make running design programmes easy and repeatable.
If any part feels heavy or bureaucratic, cut it. The goal is to focus on the product and customers, not the process.