Why I Built IdeaLift: 10 Years of Watching the Same Decisions Get Relitigated

There's a ticket I think about a lot.

At MillerKnoll — the parent company behind Herman Miller and Knoll — I spent four years as a WMS Programmer and Senior Systems Engineer. My job was building efficiency into warehouse management systems, automating the tedious stuff so operations teams could focus on what actually mattered.

One ticket came up over and over: cancelled orders flowing back into the host ERP system incorrectly. On the surface, it was a simple fix. Five minutes. One stored procedure change.

But when it went to QA, it exposed a myriad of issues with partial fulfillments. Cancelling an order that was partially shipped opened a can of worms nobody wanted to deal with — inventory reconciliation, fulfillment state machines, downstream integrations that all assumed orders were either open or fully complete.

So every few months, the ticket would resurface. Three or four of us would get pulled into a meeting to re-hash where we stood on it. We'd walk through the same analysis. Reach the same conclusion: with the on-prem to SaaS migration coming and the integrations moving from C# to AWS, the juice wasn't worth the squeeze. Not enough frequency to justify the complexity.

Then six months later, we'd have the exact same conversation.

Not because anyone forgot. Because there was no record of the decision. No system that said "we discussed this on these dates, here's why we deferred it, here's the threshold that would change our minds." Just institutional memory spread across four people's heads — and eventually, someone new would join the team and the whole cycle would restart.

It's Not One Big Problem. It's a Thousand Small Cuts.

That MillerKnoll ticket wasn't unique. It was a pattern I saw at every company across 10+ years in IT.

The teams were always good. Smart people, solid processes. But tracking decisions — the why behind what you shipped and what you didn't — was never easy. Especially with multiple items in flight, which was nearly every team I worked on.

The context existed. It was in Slack threads, email chains, meeting notes that nobody could find three months later. The problem was structural: every communication tool we used was ephemeral by design. Today's critical discussion is tomorrow's buried thread.

Here's what decision decay actually looks like across a quarter:

• Week 1: A signal comes in. Someone flags it in chat. Two people discuss it. Good context, clear reasoning.
• Week 4: At planning, someone asks "didn't we talk about this?" A PM spends 20 minutes searching Slack. Finds a thread, but not the thread. Half the context is missing.
• Month 3: A new stakeholder asks why Feature X isn't on the roadmap. Nobody can explain the decision coherently. The team spends an hour rebuilding the case from scratch.
• Month 6: The same signal comes in again. The cycle repeats.

Multiply that by every decision a product team makes, and you're bleeding hours every single week. Not on bad decisions — on repeating decisions that were already made.

What I Tried Before Building IdeaLift

Before I wrote a single line of code, I tried every solution I could find:

Jira tags. Created labels and categories to track decision rationale. The tickets got tagged, but they were skeletal — "Deferred: cancelled orders fix" with none of the context about why it was deferred or what conditions would change the decision.

Spreadsheets. Built elaborate tracking docs. They worked for about two weeks before people stopped updating them. The friction of switching from where the conversation was happening to a separate spreadsheet was too high.

Archived emails. Searched back through email chains looking for the original discussion. By the time you found it — if you found it — the context was fragmented across 15 reply-all threads and three people had since left the company.

None of it worked. Not because the tools were bad, but because every solution required people to do extra work outside their normal flow. Under deadline pressure, "I'll document that decision later" becomes "I forgot" every single time.

From Fallujah to Firmware: Why Accountability Stuck With Me

Before IT, I was in the Marines — infantry, 2003 to 2007. Combat deployments to Fallujah, Iraq and Bagram, Afghanistan.

Then Army Reserves from 2007 to 2010, training deploying troops on what I'd learned overseas.

In the military, accountability isn't optional. When you make a decision in the field, it gets logged. There's a record of who decided what, when, and why. Not because of bureaucracy — because when lives are on the line, you need to be able to trace the reasoning behind every call.

Product decisions aren't life-or-death. But the principle is the same: when a decision matters, the reasoning behind it matters too. And if you can't trace back to why you decided something, you end up relitigating it — wasting time, energy, and trust.

That military mindset — decisions have owners, decisions have records, decisions have consequences — is baked into everything IdeaLift does.

The Accidental Origin Story

IdeaLift didn't start as a decision intelligence platform. It started as a workflow automation tool.

A fellow developer at MillerKnoll had a simple problem: he wanted to capture ideas from Twitter and pull them into the GitHub backlog, rather than referring back to chat every time. A lightweight pipeline from signal to ticket.

We built a prototype. It worked. And then I couldn't stop thinking about it.

As a WMS programmer for over a decade, my entire job had been finding efficiency for the users I supported — simplifying or automating tasks within the constraints of the application. Now I was doing the same thing for myself. How do I improve this flow? How do I provide the most value?

The answer kept expanding: it's not just about capturing ideas from one source. It's about capturing decisions from everywhere — Slack, Teams, Discord, email, meetings — and preserving the context that makes those decisions stick.

The feature request pipeline was table stakes. The real value was the decision intelligence layer — knowing who decided what, when, and why, so the team never has to relitigate it.

What IdeaLift Actually Solves

IdeaLift sits between your communication tools and your execution tools. Instead of asking people to manually extract information from conversations and re-enter it into a tracking system, you point at the conversation and say "capture this."

One emoji reaction in Slack. One command in Teams. IdeaLift captures the full thread context — who said what, when, what the conversation looked like — and structures it into something your backlog tool can act on.

Every captured signal includes:

• Full conversation context — not a summary, the actual thread
• Source attribution — who said it, where, when
• Decision trail — when the idea is approved, deferred, or rejected, IdeaLift records who decided and why
• One-click sync — to Jira, Linear, GitHub Issues, Azure DevOps, or Notion

When someone asks "why didn't we build Feature X?" there's an answer. Not a guess. Not a reconstructed memory. An actual record of the conversation, the signals, and the decision.

The MillerKnoll Ticket, Solved

If IdeaLift had existed during those four years at MillerKnoll, that cancelled orders ticket would have been a 30-second lookup instead of a 45-minute meeting.

The first time we discussed it, someone would have captured the decision: "Deferred — partial fulfillment complexity too high relative to incident frequency. Revisit after SaaS migration." With the full thread context, the QA findings, and the names of everyone involved.

The next time it came up, instead of reassembling four people for another meeting, anyone on the team could have pulled up the decision record, seen the rationale, and either confirmed it still applied or escalated with new evidence.

That's the difference between having information and having it accessible. Most teams have the context. They just can't find it when it matters.

For Every Team That's Had the Same Meeting Twice

I built IdeaLift because I lived this problem for a decade and couldn't find a tool that solved it. Not because the people were bad — every team I worked with was excellent. Because the systems we use for communication are fundamentally ephemeral, and the systems we use for execution don't capture why.

If you've ever searched Slack for 20 minutes trying to find "that thread where someone mentioned the feature" — or sat through a meeting that felt like a rerun because nobody could remember the original decision — you know exactly what problem we're solving.

Decision decay isn't a people problem. It's a systems problem. And it finally has a solution.

---

Tom Pinder is the founder of IdeaLift. Before building decision intelligence software, he spent 10+ years as a WMS Programmer and Senior Systems Engineer at companies including MillerKnoll, and served in the United States Marine Corps (2003-2007) with combat deployments to Fallujah, Iraq and Bagram, Afghanistan. Connect on LinkedIn.