thaman✳︎
Say hello
VECTORSHIFT / PRIORITISATION

Sometimes the call is what to stop.

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

THE 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.

WHAT CHANGED

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
06 / FOLLOW THE USAGEUsage dataHow customers workDecisionOne roadmapDocumentsPrioritiseTablesDeprioritiseSTOPPING WORK IS A DECISION TOO
06 / FOLLOW THE USAGEUsage dataHow customers workDecisionOne roadmapDocumentsPrioritiseTablesDeprioritiseSTOPPING WORK IS A DECISION TOO
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

Constraints

  • 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

  • NOT CHOSEN

    Keep both at a reduced pace

    It feels fair and ships two half-finished products.

  • NOT CHOSEN

    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 (decision memo)

spec / documents-over-tables.mdVectorShift

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.

HONEST CAVEATI 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.

Last updated · Company tenure is VectorShift · Jul 2025–present, not a claim about individual project dates.