Pillar 4: Tools

Key Takeaways

‍

• Every collaboration purpose (messaging, task management, documentation, design, analytics) needs a designated source of truth. Overlap creates confusion, gaps create blind spots.
• The specific products matter less than ensuring every purpose is covered and the whole team knows where to go for what. We have defaults that work well for our projects, but we adapt when a client's existing tools already serve the same purposes.
• All tools are created under the client's ownership, so the team has full access and visibility into progress at all times. No black boxes, no "ask the agency team for an update."
• A well-configured tooling setup eliminates the "where does this live?" tax that quietly eats hours every sprint, especially when your team spans multiple locations and time zones.

‍

Why Collaboration Infrastructure Matters

‍

When a team doesn't have a shared, explicit agreement on which tools serve which purposes, every handoff introduces friction. Design specs get shared in a message but never make it to the project documentation. Decisions get made on a video call but nobody captures them. Sprint progress lives in one place, discovery work in another, and stakeholder updates in a third. Each of these gaps is small on its own, but they compound. Within a few weeks, team members are operating on different versions of reality.

‍

That friction multiplies when your team works across time zones and locations. If you're in the same office, you can tap someone on the shoulder and ask "where's the latest mockup?" When your team is distributed, that question turns into a message that sits unanswered for hours, or worse, gets answered differently by two people. The collaboration infrastructure has to do the work that physical proximity used to handle for free.

‍

The companies we work with are usually capable, well-resourced teams. They don't have a skills problem. They have a "where does this live and who's responsible for keeping it current" problem. That's what the Tools pillar solves.

‍

How We Set Up Collaboration

‍

We organize collaboration around core areas that every product team needs covered. Below is what we set up at the start of most engagements, though we regularly adapt to a client's existing stack when their tools already serve the same purposes well. The specific product names are what works for our teams and projects, not a prescription.

‍

Communication

‍

Effective distributed collaboration starts with structured communication. The team needs a place for instant messaging that's organized by topic, not scattered across DMs and email threads. We typically use Slack, configured into specific channels: #general for cross-team updates, #design for design discussions, #engineering for technical conversations, #management for leadership-level coordination, #bugs for defect reporting, #releases for deployment tracking, and #standup for async daily updates. The channel structure matters because it makes conversations searchable and keeps context where it belongs.

‍

Video conferencing covers all meetings and ceremonies. Standups, sprint planning, retros, stakeholder demos, discovery sessions. We default to Google Meet, and the project schedule lives in Google Calendar so every team member has visibility into what's happening and when.

‍

Task management

‍

The team needs a single place where work is tracked from refinement through delivery, with enough structure that anyone can see the state of work without asking someone. We use Jira with two boards: a Scrum board for the delivery track and a Kanban board for discovery work. This separation maps directly to our Dual-Track Agile approach, keeping both tracks visible without forcing them into the same workflow. Reports give the Product Lead and Tech Lead real-time visibility into team capacity and timeline without having to chase anyone down.

‍

Documentation

‍

Project documentation needs a home that's structured for multiple audiences: onboarding materials for new team members, project status for stakeholders, technical documentation for in-house transitions, and organized records for due diligence processes. We use Confluence for this, and when documentation lives in one well-structured place, nobody has to ask "where's the latest spec?" because the answer is always the same. Google Drive handles documents that don't fit neatly into a wiki: brand assets, user stories drafted in Sheets, presentations, and other files.

‍

Design and research

‍

All digital product design, prototyping, and usability testing lives in Figma, where the Design Lead maintains the design system and the team uses it for prototype testing during discovery. Miro handles virtual whiteboarding for user flows, system charts, lo-fi wireframes, and brainstorming sessions. When boards are finalized, they get embedded in Confluence so everything traces back to the documentation layer.

‍

Analytics and qualitative insights

‍

The team also needs a data layer that feeds discovery work and helps validate whether shipped features are actually getting used the way they were designed to be. We use Hotjar for heatmaps, session recordings, surveys, funnels, feedback widgets, and user interviews. If a client already has a tool that covers qualitative insights (FullStory, Heap with session replay, etc.), we'll use that instead. The purpose matters more than any specific product.

‍

Client Ownership and Transparency

‍

One thing we're deliberate about: all tools are created under the client's ownership. This isn't a minor administrative detail. It means your team has full access and visibility into the project at all times. You can see sprint progress in real time, read every piece of documentation, review every design file, and monitor every conversation in the project channels. There's no "we'll send you a status report on Friday" gatekeeping.

‍

This also means that when an engagement ends, everything is already yours. Jira boards, Confluence documentation, Figma files, Slack history. There's no knowledge transfer scramble or data migration. Your team picks up exactly where things are, with full context, because they've had access to everything from day one.

‍

Adapting to Your Stack

‍

We're not married to any of these products. If a client already uses Linear instead of Jira, Notion instead of Confluence, or Microsoft Teams instead of Slack, we adapt. What we won't compromise on is coverage: every collaboration purpose needs a clear, agreed-upon tool, and the whole team needs to know the map.

‍

The problems show up when purposes overlap (two tools doing the same thing, so nobody knows which is canonical) or when there are gaps (no designated place for a specific type of information, so it ends up scattered). We sort that out in the first week of every engagement and revisit it if the setup starts creating friction.

‍

What This Means in Practice

‍

Here's how our teams get the tooling infrastructure right from the start of every engagement.

‍

1. We map every collaboration purpose to a single source of truth

‍

In the first week, we identify every type of collaboration the team needs (messaging, task tracking, documentation, design, analytics, scheduling) and assign each one to a specific tool. If the client already has tools in place, we evaluate whether each purpose is actually covered or just assumed to be. The most common finding is that documentation and task management have gaps or overlaps that the team has been working around without realizing it.

‍

• Validate by asking a few team members: "Where would you go to find the current sprint status?" or "Where do design specs live?" If we get different answers from different people, the tooling map has holes.
• Red flag: The team uses their messaging platform as a de facto documentation layer. Decisions, specs, and status updates live in message threads that disappear into the scroll. That's a sign there's no real documentation home.

‍

2. We configure tools to match the team's actual workflow

‍

Setting up a task management board is one thing. Configuring it so the columns, statuses, and workflows actually match how the team works is another. We set up boards to mirror the delivery and discovery tracks, structure documentation so it's findable by role and purpose, and configure communication channels so conversations don't bleed into each other. The goal is that the tools reinforce the process, not fight it.

‍

• Validate by checking whether the team actually uses the tools as configured, or whether they've built workarounds (side channels, personal docs, spreadsheet trackers). Workarounds mean the configuration doesn't match reality.
• Red flag: The team has a task management tool but sprint planning still happens in a spreadsheet or a Google Doc. The tool isn't doing its job if the team doesn't trust it to reflect the real state of work.

‍

3. We revisit the setup when it starts creating friction

‍

Tooling isn't set-and-forget. As teams grow, priorities shift, or new workstreams spin up, the collaboration infrastructure needs to evolve. We pay attention during retros for signals that tools are becoming a bottleneck: complaints about finding information, duplicated tracking, or processes that worked at five people but break at fifteen.

‍

• Validate by listening for recurring friction in retros. If "I couldn't find X" or "I didn't know Y was decided" comes up more than once, the tooling map needs an update.
• Red flag: The team added new tools organically without removing or consolidating old ones. Three overlapping project tracking systems is worse than one imperfect one.

‍

Common Questions About Tools

‍

Q: We already have our own tools in place. Does OAK'S LAB require us to switch?

‍

A: No. We adapt to your stack as long as every collaboration purpose is covered. If you're using Linear, Notion, and Microsoft Teams and they're working well, we'll work within those. What we will flag is if there are coverage gaps or overlaps. If your documentation lives partly in one platform and partly in another with no clear rule for which goes where, we'll work with you to sort that out. The tooling itself is secondary to the "one purpose, one source of truth" principle.

‍

Q: How do you handle teams that are distributed across multiple time zones?

‍

A: That's actually one of the main reasons this pillar exists. When your team is co-located, a lot of communication happens informally. You overhear conversations, you see what people are working on, you grab someone for a quick question. Distributed teams lose all of that, so the collaboration infrastructure has to compensate. Structured channels replace hallway conversations. Async standups bridge time zone gaps. Documentation becomes the default medium for decisions rather than an afterthought. We configure the tooling setup with the assumption that not everyone is online at the same time, which means decisions and context need to be visible and searchable without requiring someone to be in the room when it happens.

‍

Q: How does the transition work when an engagement ends and the client takes over the tools?

‍

A: Because everything is set up under your ownership from day one, there's no transition to manage in the traditional sense. Your team already has full access to every tool, every board, every document. We structure Confluence so it makes sense to someone who wasn't there when it was written. Task management boards are configured with clear workflows, not tribal knowledge about what each status means. The goal is that when our team steps back, your team can pick up exactly where things are without a knowledge transfer scramble. This is also why we prefer well-documented, mainstream tools over bespoke setups.

‍

Q: How does Confluence documentation support due diligence and investor processes?

‍

A: We structure project documentation so that technical decisions, product history, and process records are organized and accessible. When a due diligence process or investor review comes up, the information is already there rather than scattered across message threads, personal documents, and someone's memory. Teams that have been through a fundraise with this kind of documentation in place consistently report that the process was less painful than expected, largely because they weren't scrambling to reconstruct decisions and timelines after the fact.

‍

Q: What's the biggest tooling mistake you see teams make?

‍

A: Using their messaging platform as the source of truth for everything. Decisions get made in threads, design feedback lives in DMs, project status is whatever someone last said in a channel. It feels efficient in the moment because everyone's already in the messaging app. But a few weeks in, nobody can find anything, context disappears into the scroll, and new team members have zero way to get up to speed because the project's institutional knowledge is buried in thousands of messages. The fix isn't complicated: designate the right home for each type of information and make it a team habit to put things there instead of just discussing them in chat.