In Glint, the biggest gap against the market was a manual process: refunds requested by email. Prioritizing meant finding that work, ordering the rest by what depended on what, and writing down what would stay manual, on purpose.
Anderson Silveira · September 21, 2026
Glint is an event platform I built in about three weeks: ticket sales, the door, attendee relationships, and post-sale in a single product. In three weeks, there’s no shortage of requests. Each batch brought new functionality, and each one seemed like the most important.
The turning point was a comparison with a competing platform. The conclusion had two sides. Glint already had more than 24 features the competitor didn’t: sections, CRM, automation, certificates, affiliates with their own portal. And the competitor had the edge on five points, with one ahead of all the others: self-service refunds. Under the right of withdrawal in Brazil’s Consumer Protection Code, attendees have seven days; in Glint, that was still a manual process, handled by email, slow and full of friction for both sides.
The naive reading of the comparison would have been to celebrate the 24. The useful reading was the other one: one more feature where the product already won moved very little; closing gap number one changed the sales conversation. Post-sale went live two days later: within the window, the attendee requests the refund in the app and the money goes back immediately; outside it, the request becomes a ticket for the organizer to approve or decline. The rule became automatic. The exception stayed human.
This article is about the method behind that kind of choice: which manual work to automate first, in what order, and what to leave manual on purpose.
Priority for what
No technique works without knowing impact on what. In Glint, the criterion that ran through everything was a split made before any screen: core and extras. What every organizer needs (event, ticket, checkout, check-in, finances) is core. Everything else is extra.
That split became a prioritization rule and, later, a commercial rule. The model has three plans, and the free one covers the entire core. If a subscription payment fails, the account drops back to basic: the organizer loses the extras, never the event they’re selling. A question like “does this go in now?” gets a first filter: is it core? If it is, and it’s broken or missing, it comes before any extra.
Three questions for every manual task
Before putting a manual process on the matrix, I run through three questions. They don’t produce a score. They produce something to compare.
| Question | What it reveals | Example |
|---|---|---|
| How often does it happen? | How much time the automation gives back | In Glint, any attendee can request a refund; affiliate commissions close by period and fit in a report paid by hand |
| What does it cost when it goes wrong? | How much human review the automation needs | In a distributor’s ordering system, getting the packaging wrong on a 200-liter drum isn’t cheap. So the AI proposes and the buyer confirms |
| Is the rule written down? | Whether it can be automated without someone deciding case by case | Within seven days, a refund is the attendee’s right: clear rule, automatic refund. Outside the window, it’s the organizer’s call |
The third question is the one that separates the most. A clear rule becomes automation. A rule that depends on context becomes a queue for someone to decide, with the machine only preparing the decision.
Impact × effort matrix
The simplest tool, and often enough. The items below are from Glint; the positions are my reading in hindsight, not a measurement.
The matrix pays off most as a group exercise. The value is in the discussion when two people put the same item in different quadrants; almost always, one of them knows something the other doesn’t.
RICE, when the list is long
The matrix gets fragile with many similar items. RICE, created at Intercom, adds how many people are affected and how confident the team is:
| Item (illustrative example) | Reach | Impact | Confidence | Effort | RICE |
|---|---|---|---|---|---|
| Clearer error message at payment | 8,000 | 0.25 | 100% | 0.5 | 4,000 |
| New sign-up flow | 2,000 | 1 | 80% | 2 | 800 |
| Reporting module | 500 | 3 | 50% | 4 | 187.5 |
The best thing about RICE is that it makes visible the unglamorous item that reaches a lot of people. The worst is false precision: 187.5 is the product of four estimates. Close scores are a tie. Use the number to separate groups, never to break ties by decimal places, and record where each value came from.
Dependencies order the queue too
Value tells you what matters. It doesn’t tell you in what order you can build. In Glint, this became explicit in a 16-task initiative: product catalog, CRM, funnel, certificates, attendees, the reorganization of the event tabs. A discovery done before execution produced one brief per task and a conflict map: which tasks touched the same screens and the same files.
The order came out of that map, in six waves:
- 01Foundation
Tabs component built once and database changes consolidated.
- 02Isolated pages
Customers, funnel, certificates, and main dashboard, in parallel.
- 03Second parallel batch
Products, event overview, and engagement.
- 04Event editor
Days, tickets, and attendees, in series: they share the same screen.
- 05Deliverables
File upload, on top of the screen the previous wave finished.
- 06Event menu
A single owner reorganizes the tabs at the end, from 14 to 12 items.
The last wave is the lesson. Reorganizing the menu looked like the most visible task, and therefore the most tempting to do first. Done first, it would have conflicted with every other task. Done last, it became stitching together items that already existed.
A wave-based roadmap is also the most honest way to say “not now.” In Kitnets, discovery turned into 29 epics in three waves. The epics that depended on an approved account with an external service, on a timeline I don’t control, were left for later. When a dashboard needed billing data that didn’t exist yet, the cards went in disabled, with a note that they’d arrive along with billing, instead of showing fake numbers.
Sequence: what clears the way for what
Sometimes the order comes from the funnel itself. At Zeztra, the website with simulators and a diagnostic, each one giving value back before asking for contact info, came first. With it live, Zeztra’s campaigns started to need pages by topic, and only then did the survey engine, one page per topic, make sense. Building the engine first would have meant prioritizing scale with nothing to scale.
In Glint, the marketing track followed the same logic, in six steps: a coupon valid for one event or for all of them, affiliates as an organizer entity, the affiliate portal, a public event storefront, platform affiliates promoting any organizer, and finally, automatic commission splitting. The first five shipped the same day, each one building on the previous. The sixth was postponed on purpose.
The list of what stays manual
The most useful artifact of a prioritization is what was left out, with the reason and the condition for bringing it back. Not every manual task needs to become an automation right now.
| Item | Why not now | What would change that |
|---|---|---|
| Automatic affiliate commission split (Glint) | Requires identity verification for each affiliate; commissions as a report, paid manually, solve the problem for this period | An affiliate volume that makes manual payment unworkable |
| Different per-event commission for the same affiliate (Glint) | One percentage per affiliate covers current usage | Recurring requests from organizers |
| Billing and revenue in the platform dashboard (Kitnets) | Depended on subscriptions, which didn’t exist yet | Subscriptions going live |
The first row is manual work kept on purpose. While there are few affiliates, paying commissions by hand from a report costs less than verifying each one’s identity. The automation waits for the volume that justifies it.
The third column turns a “no” into a decision that can be revisited. Whoever asked knows what would need to happen, and nobody relitigates the same thing every week.
What I’d do differently
- Lock down the plan map before building the gating. In the first version, plans launched with everyone on the full plan, so nobody would lose access. When self-service sign-up went in, the map was redone: products, customers, and coupons moved down to the free plan. It worked because the rule lived in a single file, but it was decision rework.
- Pin down contracts between parallel tasks. In the platform dashboard, two parallel tracks agreed on different names for the same numbers, and the metrics screen opened blank. Parallel waves need a written contract up front, not just a file map.
- Do the comparison earlier. It came after much of the product was built, and it showed that the biggest gap was in post-sale. Done at the start, it would have weighed on the order of the first batches.
Prioritization checklist
- Is there one written outcome for the period, and only one?
- Is the core separated from the extras, and does the core come first?
- Was each candidate manual task assessed for frequency, cost of error, and clarity of the rule?
- Was the market comparison read for the gaps, not just the advantages?
- Was the matrix built as a group, and were the disagreements discussed?
- In RICE, is the source of each number recorded, and are close scores treated as ties?
- Does the order account for dependencies and conflicts, not just value?
- Do parallel tasks have a written contract between them?
- Is there a list of what stays manual, with a reason and a condition for reopening?
If nobody felt uncomfortable about what stayed manual, the prioritization probably didn’t choose anything.