Why system archaeology isn’t the best way to gather feature ideas from customers

So you want ideas from potential customers, and you want them to be rich, actionable, and, yes, tasty enough to feed a roadmap. Easy to say, harder to do. There are several techniques you can use, and not all of them are equally effective when the goal is to surface new features from real users. In a moment, I’ll name the least suitable one and then walk you through why it misses the mark for this particular mission—and what to use instead.

Let me explain the four techniques in plain terms

• Change of perspective: You put yourself in the user’s shoes. You ask questions like, “If I were a user in this situation, what would I want next?” It’s about empathy first, ideas second. The magic here is discovery—people reveal needs when they’re seen from a different angle.

• Brainstorming: A classic group exercise where people shout out ideas, ideally without judgment, and you jot them down. The goal is to flood the room with possibilities, sometimes wilder than what you’d put on a wishlist. It works best when you want a broad funnel of ideas and you keep the energy high.

• System archaeology: Picture a detective’s work—peeling back the layers of an existing system, mapping components, interfaces, and dependencies. The aim is to understand what’s there, why it’s there, and the constraints that shape what can be built next.

• Analogy technique: You compare your product domain to a different field with well-taved features. By drawing parallels, you spark creative thinking and pull ideas from other contexts into your own space.

Why system archaeology is the least suitable for gathering feature ideas

Here’s the thing: system archaeology excels at diagnosis, not ideation. It’s a deep dive into the bones of what exists—the architecture, data flows, integration points, and the like. It helps you answer questions like: “Why is this component this way?” or “Where do bottlenecks live?” That’s incredibly valuable for engineers and architects, but it’s less effective when your objective is to surface new features that satisfy users’ unspoken needs.

Think of it this way: you’re trying to harvest fresh ideas directly from the people who’ll use the product. System archaeology, by its nature, looks at what’s already there and why it’s structured as it is. It tends to focus on constraints, maintenance, and compatibility rather than on what users dream of or what would genuinely delight them. It’s like examining the skeleton of a car to decide what new color to paint it—you might learn a lot about durability, but you won’t get a trove of new features by staring at gears alone.

That doesn’t mean system archaeology is useless. It’s a fantastic background activity for teams that want to respect existing realities, avoid costly missteps, and ensure any new ideas can actually be built. It just shouldn’t be your primary engine for generating feature ideas from customers.

What actually generates robust feature ideas from customers

• Change of perspective nudges the mind toward user-centered needs. When you frame questions from the user’s vantage point, you invite problem statements that map directly to value.

• Brainstorming creates an energy buffet of possibilities. The trick is to capture every idea, then prune them with a clear tie to user value and feasibility.

• Analogy turns the familiar into the fresh. By comparing your domain to other industries or apps, you unlock features you might not consider if you stayed in a single lane.

How to run a customer-centered idea session without getting lost

If you want a practical, go-to method that yields concrete, user-relevant features, consider a small, well-structured session that blends these techniques. Here’s a simple blueprint you can adapt.

Step 1: warm-up with a change of perspective (10 minutes)

• Invite participants to describe a recent moment where something about the product annoyed them—or where something delighted them.

• Then flip the perspective. Ask: “From the point of view of a first-time user with no training, what would make this smoother?” or “If this feature was a gadget in a totally different industry, what would it do for you?”

• The goal: loosen default assumptions and lift latent needs to the surface.

Step 2: gather raw ideas through brainstorming (20–25 minutes)

• Ground rules matter: defer judgment, aim for quantity, build on others’ ideas, don’t censor wild notions.

• Use prompts that tie to real jobs users hire the product to do. For example: “What must this feature help you accomplish by Friday?” or “Where do you hit friction repeatedly?”

• Capture ideas on sticky notes or a digital board. Don’t worry about feasibility yet—this is about exploration.

Step 3: spark analogy-driven insights (15 minutes)

• Take two minutes to describe a familiar, unrelated system that solves a similar problem in another space (think ride-hailing, smart thermostats, or fitness trackers).

• Ask: “What feature from that space would translate well here, and why would it help our users?”

• The point isn’t to copy; it’s to transplant a proven concept into your context with thoughtful adaptation.

Step 4: synthesize and prioritize with guardrails (15–20 minutes)

• Cluster ideas by user value, impact, and rough effort. Keep it light—high-level feasibility cues are fine at this stage.

• Use a simple prioritization scheme, like “Must-have, Nice-to-have, Not now,” and track rationale for each decision.

• End with a quick recap: which ideas feel most compelling to users, and which are most feasible to validate with small experiments.

Tips to keep the session productive

• Invite diverse voices: frontline sales, support, onboarding, development—different angles converge on real needs.

• Use real user stories or jobs-to-be-ddone framing to anchor ideas in outcomes.

• Avoid leading questions. Let users describe their pain first; the initiative to propose a feature should come from them, not you.

• Capture the essence in a sentence per idea: “Users want X to achieve Y.” That makes it easy later to map to acceptance criteria.

Practical prompts you can reuse

• For change of perspective: “If this app disappeared for a week, what would a user miss most, and why?”

• For brainstorming: “What one capability would make users feel instantly more competent in their day-to-day tasks?”

• For analogy: “In a different field, what feature solves a problem that’s similar to ours? How would it look here?”

• For synthesis: “Which idea would reduce the most user friction without expanding the system’s surface area?”

A quick note on scope and quality

Ideas without a clear connection to user value can wander off into space. It helps to keep a tight link to outcomes users care about. If a proposed feature is elegant but adds little real value, it’s not wasted—just tagged for later exploration in a different context. And yes, you’ll end up with some wild ideas. That’s not a mistake; that’s the spark you need to uncover surprising, credible needs.

How this fits into a broader requirements effort

Surfaces like this are best treated as input into a structured discovery process. You don’t want to ride on a single session’s momentum. Combine findings with other sources: user interviews, analytics signals, customer support tickets, and field observations. The aim is a coherent picture of both what users want and what the product can support realistically.

A few concrete examples to bring it home

• Imagine you’re tweaking a personal finance app. A change of perspective prompt might reveal a user pain: keeping track of subscriptions is tedious. Brainstorming could surface ideas like a unified subscription dashboard, automated reminders, and price-change alerts. An analogy—compare with smart home dashboards that aggregate devices—could inspire a feature that visualizes recurring costs as a “monthly kitchen bill.” System archaeology would remind the team to consider data flows and privacy constraints, ensuring any new feature integrates cleanly with existing authentication and data stores.

• For a health-tracking app, perspective shifts could surface the need for a simpler goal-setting flow. Brainstorming might generate ideas around auto-suggested workouts, progress nudges, or social accountability features. An analogy could be drawn from project management tools that translate tasks into clear milestones. Archaeology would help you understand data provenance, ensuring new metrics don’t violate consent or privacy policies.

Common pitfalls to avoid

• Don’t treat system archaeology as your primary source of ideas. It’s tempting to start there to map constraints, but you’ll end up with a backlog of feasibility puzzles rather than customer-centered features.

• Avoid endless debates on feasibility in the early stages. It’s fine to flag obvious blockers, but the purpose here is discovery, not decision-making about release dates.

• Watch for echo chambers. If only one department speaks up, you’ll miss other user segments. Bring in varied voices and voices from outside the usual circles.

Bringing it back to the bigger picture

The best way to surface meaningful features from customers is to blend empathy with creativity, then ground those ideas in the product’s reality. Change of perspective, brainstorming, and analogy techniques are your friends here; system archaeology, while valuable for understanding constraints, should stay in its lane as a complementary background activity. When you mix these methods thoughtfully, you’ll gather ideas that feel both fresh to users and feasible to build.

If you’re shaping a research or product-learning cadence, here’s a simple takeaway: use user-centered conversations to spark ideas, then validate the most promising options with small experiments and real-world feedback. The sequence matters. Start with human insight, then test the waters of feasibility. The goal isn’t to produce a long list of features; it’s to uncover high-value opportunities that your team can realistically translate into better user outcomes.

A gentle nudge to wrap this up

Next time you set out to gather feature ideas from potential customers, skip the instinct to rely on one single method. Build a small, dynamic mix—perspective shifts to warm the brain, a brisk brainstorming sprint to collect possibilities, and a dash of analogy to unlock unfamiliar angles. Let system archaeology be the quiet backbone that helps you understand the scaffolding, but don’t let it steal the show from the people who matter most—the users.

If you’re exploring how teams gather meaningful customer-driven ideas, it’s not about chasing a perfect method. It’s about choosing the right tool for the moment and keeping the focus on real needs, clear value, and practical pathways to action. After all, ideas that resonate with users and survive a careful, thoughtful process are the ones most worth pursuing.

If you’d like, I can tailor a short workshop plan for your team or help you convert a batch of raw ideas into a prioritized backlog with clear user stories and acceptance criteria. The right blend of human insight and practical structure can turn a roomful of ideas into something your users will genuinely appreciate.