# Sometimes the call is what to stop.

A prioritisation call at VectorShift. Usage data said Documents, so I deprioritised Tables and focused the roadmap.

Company: VectorShift

Contribution: Product decision

Company tenure: VectorShift · Jul 2025–present. This is not a claim about individual project dates.

Context: Decided on usage data

## TL;DR

Problem: Documents and Tables were competing for the same engineering time, and Tables looked like the obvious bet for finance users.

My call: Prioritise Documents and deprioritise Tables, based on usage data.

Outcome: The team stopped splitting attention, and roadmap effort went where customers were already working.

- Documents in, Tables paused: 1 call
- What decided it: Usage data
- Person org the roadmap serves: ~20

## Context

- Company: VectorShift (YC S23)
- Decision type: Deprioritisation
- Evidence: Product usage data
- Org: Roughly 20 people across engineering, QA and design

Conceptual decision flow. Usage data is compared across two products. No real usage values are shown.

## The problem

VectorShift was building both a Documents product and a Tables product.

On paper, Tables was the safer bet. Finance teams live in spreadsheets, and a table feels familiar.

With one roadmap serving roughly 20 engineers, QA and designers, moving both forward meant neither got the attention it needed.

Evidence: Usage data pointed to Documents. Familiarity with spreadsheets was an argument for Tables. Actual usage was not.

## Constraints & non-goals

The call had to rest on evidence, not on which product felt more intuitive.

Anyone using Tables needed a clear path, not a surprise.

The reasoning had to make sense to the people who had built Tables.

Out of scope: Deleting Tables outright. Treating the decision as permanent whatever the data says later.

## Options I weighed

Rejected: Keep both at a reduced pace It feels fair and ships two half-finished products.

Rejected: Prioritise Tables because spreadsheets are familiar Familiar is not the same as used. The data did not support it.

Chosen: Prioritise Documents, deprioritise Tables Usage showed where the value was. Concentrating there was the faster path to a product customers depend on.

## The spec

Users: Customers using Documents. Customers and internal teams relying on Tables.

Requirements: Move Tables capacity onto the Documents roadmap. Explain the change and the data behind it to everyone affected.

Acceptance criteria: No active Tables user loses access without notice. The data and reasoning are written down so the call can be revisited.

Guardrails: Keep watching Tables usage for signs the call was wrong. Revisit if demand appears that Documents cannot serve.

## What shipped

1. Measure. Look at how customers were actually using both products.

2. Compare. Set the usage picture against the cost of carrying both.

3. Decide. Prioritise Documents. Deprioritise Tables.

4. Communicate. Explain the call, the data and what would reverse it.

## What changed

Roadmap effort moved to Documents, where the usage was.

The team stopped splitting attention across two products.

It is one of the calls I stand behind most, because the evidence made the argument.

I describe the decision and the evidence for it. I’m not attaching a revenue or retention number I can’t defend.

## Reflection

Stopping work is a product decision with the same weight as shipping. It deserves the same standard of evidence.

If I did it again, I would write down the reversal trigger when making the call: the specific usage signal that would bring Tables back.

The takeaway: Stop what the evidence does not support, even when it looks like the obvious bet.

Last updated: 2026-09-13