← Back to Work

Threshold

A daily briefing tool that turns scattered tools and channels into a prioritized, source-linked digest.

A daily task management tool I made for my summer internship. PMs were overwhelmed by endless channels of communication and information, so I made a tool that weeds out all of the noise to create clear signal.

Access the Project →

---

Overview

Problem, Solution, Role, Status

Problem: Employees lose time every day manually reassembling scattered decisions and tasks across Slack, Drive, meeting notes, project trackers, and more. For consulting firms, this is made worse by a firm's internal tool stack differing from each client's own systems.

Solution: Threshold, a personal daily briefing tool built as a Claude Artifact that synthesizes activity across an individual's connected tools into a prioritized, source-linked digest, plus a Friday client-status recap PMs can send directly to stakeholders.

My role: Sole builder, end to end, product definition through shipped prototype, internal pitch, and cross-functional technical execution (skill design, dashboard implementation, live integration testing).

Status: Working, validated tool living in Claude's ecosystem. Personal-scope tool proven end to end against real data; company-wide rollout explicitly scoped as a future decision requiring leadership sign-off, not something to quietly build without it.

---

1

Problem Framing

The starting brief was open-ended: build something AI (skill, artifact, app, etc.), either embedded into delivery work or improving how the internal team operates. Rather than start from a feature idea, I wanted to collect insights from Thresh employees as I learned about what their role looks like on the day-to-day. A clear pattern emerged: too many platforms to juggle between internal and client sources, all with rivaling information.

As per some Claude-supported research, the average consulting firm runs close to four tools to manage delivery. Workers lose close to an hour a day just switching between them, plus another half hour deciding which tool to use for a given task. That gave me a real, cited cost to design against.

---

2

Competitive and Market Research

Before writing a line of the synthesis logic, I conducted a few rounds of real competitive research:

• Consulting-specific status reporting conventions: what PMs actually need daily (triaged priorities, filtered noise) versus what they send clients weekly (a one-page, RAG-status, bullet-driven update, not an internal breakdown). This directly shaped the decision to build two distinct outputs, a daily digest and a separate weekly client recap, rather than one document trying to serve both audiences.
• Native competitors: ClickUp Brain, Asana Intelligence, Monday AI. All three have shipped serious workspace-level AI in the same period I was building this. I didn't treat that as a reason to stop, I used it to find the gap: every one of these tools only reasons over its own workspace. None of them synthesize across a firm's internal stack and a client's separate tools in one pass. That gap, not "AI-generated summaries" generically, became the actual differentiator and the answer to the hardest question I anticipated: why not just buy ClickUp Brain?

---

3

Scoping and Prioritization Decisions

This is the part of the project I'd point to first in an interview, because it involved real, sometimes uncomfortable, tradeoffs.

Personal tool vs. company-wide tool

Early on, it would have been easy to default to building a company-wide dashboard because it sounds more impressive. Instead, I explicitly laid out the tradeoff (data access, governance, confidentiality, realistic build time) and brought it to leadership to collect feedback for next steps. Their insight was clear: build and validate the personal-tool version fully, treating company-wide as a future path requiring its own access and governance decisions. That kept the project honest about what could actually be finished and trusted in the available time.

Killing scope creep, deliberately

At one point, I was simultaneously mid-rebuild on a new backend, mid-switch on a core integration (Linear to Jira), and mid-pivot on the frontend source of truth, three changes in flight with no working baseline. I forced myself to step back and view the project from a higher level. I chose to commit to two of the three in-flight changes, and picked the one surface (the Claude Artifact dashboard) that had ever actually been validated end to end with real data. Shipping something real beat continuing to chase a "better" architecture, especially given the time constraints.

Cutting for signal, not completeness

Every output in the final tool has a cap (max 5 priority items, max 3 dependencies, and so on) with an explicit instruction that the tool ought to return real, important items. This was a direct response to early testing feedback that the tool felt "text heavy" and was creating noise instead of removing it. Of course, this defeats the entire purpose of the product, so I knew I needed to narrow the scope.

---

4

Execution + Iteration

The build itself went through several real, evidence-driven pivots, not a single linear plan:

1. Validated the core synthesis logic first against synthetic edge cases designed specifically to break it (fabricated deadlines, invented owners, vague file references). I created a skill in Claude that perfected the architecture and built the dashboard off of it, then tested that skill against my real data to make sure it knew exactly how to handle edge cases and provide insights that were accurate reflections of what needed to be prioritized.
2. Responded to a stakeholder-driven pivot mid-build. My supervisor suggested shifting focus toward an end-of-week recap. I researched what that document actually needs to be (a client-facing status update, not an internal analytical dump) and rebuilt it as a genuinely separate artifact with its own rules, output format, and audience. Luckily, I was able to repackage existing methodology for daily insights into a client-facing end-of-week recap.
3. Iterated the interface based on direct, sometimes blunt, user feedback, moving from a dense list view to collapsible sections to a final tile-based, click-to-expand layout, with each change grounded in an actual usability complaint, not aesthetic preference. Utilized Claude Design to help create an artifact that is accessible and clear.

---

5

Cross-Functional and Technical Collaboration

Although I built this solo, the project required working across several real technical surfaces the way a PM would coordinate a small team building the same thing: a synthesis skill (the "backend logic"), a live dashboard (the "frontend"), and multiple third-party integrations (Slack, Drive, Jira, Asana, Granola, Calendar, Gmail), each with its own real constraints (rate limits, permission models, data shapes) that had to be discovered empirically, not assumed.

I also had to manage a genuine platform limitation directly: native browser features like clipboard access and confirmation dialogs don't work reliably inside a sandboxed environment. Rather than treat that as a blocker, I diagnosed the actual cause and replaced each with an in-app equivalent.

---

6

Definition of Done

Concrete, verifiable outcomes I held the project to, not vague completeness:

• Generates a real digest pulling live data from every connected source in one run, with no fabricated owners or due dates.
• Detects and correctly surfaces at least one real cross-tool dependency without it being manually pointed out.
• Never writes a change to an external system (Jira, Gmail) without explicit human approval.
• Correctly excludes content a user has explicitly marked as not their work, verified as a hard filter, not a soft preference.

---

7

Outcome

A working, personally-scoped prototype, tested against real Slack, Drive, Jira, Asana, Granola, and Calendar data, with:

• A validated synthesis pipeline enforcing strict non-fabrication rules
• A per-person connector configuration, so the same tool adapts to different individual tool stacks without rebuilding logic
• A separate, correctly-scoped weekly client status recap with a direct-to-Gmail-draft handoff
• A defensible, research-backed answer to "why build this instead of buying an existing AI feature"

---

8

Reflection

The most valuable moment in this project wasn't a feature spec or getting it to work, it was catching myself mid-scope-creep and being told directly that five half-finished directions is worse than one finished one. I believe that's a decision PMs have to face often! I had to be willing to cut work already done, including work I was personally attached to, in favor of shipping something provably real.

The second lesson was distinguishing what was my call to make versus what needed to be escalated as a real decision. Personal vs. company-wide scope and tooling standardization wasn't something to decide without collecting feedback.

I'm incredibly grateful that I was able to create this tool for Thresh. I hope you are able to check it out and use it yourself!