Most SaaS products guess what to build next. One year after launch, we threw out our assumptions and rebuilt PathPro using nothing but real customer feedback — collected through our own platform. The result was a leaner, faster product that our users actually wanted. No focus groups. No hypothetical roadmaps. Every decision backed by submissions, votes, and comments from the people using the product every day.
Why we decided to rebuild after just one year
PathPro launched with a clear vision: a community-driven product development platform where teams collect feedback, plan roadmaps, manage tasks, and ship releases in one place. The initial product worked. People signed up. But within a few months, the data started telling a story that did not match our assumptions.
Some features we had spent weeks building barely got touched. Others we had treated as minor additions were generating the most engagement. The gap between what we thought users wanted and what they actually used was significant — and widening.
We had two options. Keep iterating on the existing product and hope the engagement would catch up to our vision, or listen to what the data was actually saying and rebuild accordingly. We chose the data.
How we used our own tools to collect the data
This is the part of the story that felt almost absurd while we were living it. PathPro is a platform for collecting and acting on customer feedback. So we pointed it at ourselves.
We created a PathPro project for PathPro. Our own feedback portal, feature voting board, and public roadmap — all running on the same platform we sell to customers. Every user who logged in could submit feedback, vote on features, and comment on roadmap items. The same tools we built for other teams became the tools we used to decide what to build next.
Submissions poured in. Within the first three months, we had over 200 individual pieces of feedback. The voting system surfaced clear winners and clear losers. PathFox, our product intelligence AI, analyzed the patterns — grouping similar requests, scoring demand, and flagging themes we had missed by reading individual submissions.
The meta nature of it was not lost on us. We were using PathPro to rebuild PathPro. Every feature that made it into the redesign had to earn its place through the same process we recommend to our customers: collect, validate, prioritize, build.
What our customers actually told us
Raw feedback is messy. It does not arrive in neat categories. But when you have enough of it, the signal becomes impossible to ignore. Here are four pieces of feedback that directly shaped the rebuild.
“I see what you’re trying to do here but the UI feels too bulky and hard to figure out. I want one click access to my roadmap, feature voting, etc.”
—Jason
What this drove: This was the single most common theme across dozens of submissions. Users wanted fewer pages, fewer clicks, and more information visible at a glance. It triggered a complete dashboard consolidation — collapsing what had been separate views for tasks, roadmap items, and milestones into a unified workspace. The click count to reach any core feature dropped by more than half.
“The feature voting works great, but my team needs a better understanding about what’s being worked on.”
—Sarah
What this drove: PathPro was always designed to carry an idea through its entire lifecycle — from initial submission, to validation through feature voting, to production, and finally to shipping. The “path” of every feature is the core concept: every suggestion, vote, and conversation surrounding a feature request is preserved and carried forward as it moves through each stage.
But this feedback showed us that the connection between those stages was not visible enough. Teams could confirm a feature voting item and move it directly to the roadmap, assign it to a team member, and feature it publicly so users know exactly when it is going to go live. All of that capability existed, but users were not discovering it. This drove a complete redesign of how features flow from voting to roadmap — making the confirm-and-migrate action prominent, surfacing the full history of submissions and votes on every roadmap item, and ensuring that the public roadmap clearly showed which community requests were being actively worked on.
“We switched from Canny because we wanted everything in one place, but the task management feels like an afterthought.”
—Marcus
What this drove: This one stung, but it was accurate. Early PathPro treated task management as a secondary feature — a checkbox on the feature list rather than a core workflow. Users who had migrated from dedicated feedback tools expected the feedback side to be strong, and it was. But they also expected the task management side to be competitive with standalone tools, and it was not. This triggered a complete rebuild of the task system: subtasks, drag-and-drop prioritization, assignees, due dates, progress tracking, and a board view that actually felt like a real project management tool.
“I do not need 20 integrations. I need the core product to be rock solid. Focus on that.”
—Derek
What this drove: This was the feedback that changed our entire development philosophy. Early on, we had planned an integration marketplace — Slack, Jira, Linear, GitHub, the usual suspects. Users told us, clearly and repeatedly, that they did not care about integrations until the core product was excellent. This reinforced the lean development approach that now defines how we build. We shelved the integration roadmap entirely and redirected every hour of development time into making the existing features better.
The lean product development philosophy
The pattern across all of this feedback was consistent: do fewer things, and do them well. This is the core principle of lean product development, and hearing it directly from customers made it impossible to rationalize any other approach.
Most startups fail not because they build the wrong product, but because they build too much product. They spread engineering resources across 15 features instead of making 5 features excellent. They chase feature parity with competitors instead of solving the specific problems their users actually have.
Lean development means building only what customers ask for, validating demand before investing development time, and cutting anything that does not earn its place through real usage data. It is not about building less — it is about building the right things.
The feedback we collected through PathPro made this philosophy actionable. We did not have to guess which features to prioritize. The votes told us. We did not have to debate which features to cut. The usage data told us. Every decision had a number behind it.
What we cut (and why it mattered)
Cutting features is harder than building them. Every feature you remove is something you invested time, energy, and sometimes personal attachment into. But the data does not care about attachment.
We deprioritized the integration marketplace entirely. Early plans included native connections to a dozen third-party tools. Voting data showed this was a low priority for the overwhelming majority of users. They wanted the core platform to work better, not to connect to more things.
We simplified the notification system. The original design included granular notification controls with dozens of toggles. Usage data showed that almost nobody customized their notifications beyond the defaults. We replaced the complex settings panel with a simplified, opinionated notification system that worked well out of the box.
We removed an elaborate onboarding wizard. We had built a multi-step guided setup process that walked new users through every feature. Session data showed that most users skipped it entirely. We replaced it with a minimal onboarding flow that got users to their first meaningful action in under 60 seconds.
Each of these cuts freed up development capacity that went directly into the features users were actively requesting. Cutting is not about doing less. It is about doing more of what matters.
What we doubled down on
The feedback data pointed clearly to four areas that users cared about most. These became the foundation of the rebuilt PathPro.
The feedback portal and voting system. This was consistently the highest-rated feature. Users loved the ability to collect submissions from their communities and let them vote on priorities. We invested heavily in making this faster, cleaner, and more powerful — better search, improved filtering, richer submission detail pages, and tighter integration with the roadmap so confirmed features automatically linked back to the original submissions that inspired them.
The task management system. The rebuild transformed tasks from a basic feature into a real workflow tool. Subtasks, board views, assignee management, milestone tracking, and drag-and-drop reordering all came from direct user requests. Every addition was validated through voting before it was built.
The public roadmap. Users wanted transparency. They wanted to show their own customers what was being worked on and what was coming next. The rebuilt public roadmap became one of PathPro’s most distinctive features — a living, real-time view of the product plan that anyone could access without logging in.
PathFox. The demand for AI-powered feedback analysis was strong from the start and only grew. Users did not just want to collect feedback — they wanted help understanding it. PathFox’s expansion to cover demand scoring, theme detection, cross-project search, and conversational actions all came directly from user requests.
The results
Rebuilding a product is a risk. You are disrupting existing workflows for current users while betting that the new version will be better for everyone. Here is what happened after the rebuild shipped.
Daily active engagement increased measurably. Users were spending more time in the platform and visiting more pages per session. The dashboard consolidation meant they could accomplish more without navigating away, and the improved task management gave them a reason to stay inside PathPro instead of switching to a separate tool.
Churn decreased. The most common reason users had given for leaving was that the product felt incomplete or that they needed a separate task management tool alongside PathPro. The rebuild addressed both of those concerns directly. Fewer users left because fewer users had a reason to.
Support tickets dropped. A simpler, more focused product generated fewer confusion-related support requests. The features that remained were better documented, more intuitive, and more thoroughly tested because development resources were concentrated instead of spread thin.
Feedback quality improved. Once users saw that their feedback was actually driving changes, they submitted more detailed, more thoughtful requests. The feedback loop became self-reinforcing — better input led to better product decisions, which led to more trust, which led to even better input.
None of these results were dramatic overnight transformations. They were steady, measurable improvements that compounded over weeks and months. That is what data-driven development looks like in practice — not a single breakthrough, but a consistent trajectory in the right direction.
How to apply this to your own product
You do not need to rebuild your entire product to benefit from this approach. But you do need to change how you make decisions. Here are four practices that made the difference for us.
Collect feedback from day one. Do not wait until you have a large user base to start listening. Even 10 users giving honest feedback will tell you more than months of internal brainstorming. The earlier you start collecting, the earlier you start learning. Set up a feedback channel before you think you need one.
Let users vote. Individual feedback is valuable, but aggregate preference is more valuable. When 50 users vote for the same feature and only 2 vote for the one you were planning to build next, that is a signal you cannot afford to ignore. Popular opinion does not replace product strategy, but it should heavily inform it. Founder intuition is unreliable at scale.
Read the feedback yourself. Dashboards and vote counts are useful, but they do not capture everything. Read the actual submissions. Read the comments. The nuance in how users describe their problems often reveals opportunities that numbers alone will miss. A submission that says “I want dark mode” is different from one that says “I work at night and the white background gives me headaches after an hour.” The second one tells you the real problem.
Cut ruthlessly. A focused product beats a bloated one every time. If a feature is not generating usage, votes, or feedback, it is dead weight. Remove it or deprioritize it and redirect those resources toward the things your users are actively asking for. The hardest part of lean development is letting go of features you personally care about. The data makes it easier.
Bottom line
Building products based on customer data instead of assumptions is not optional — it is the difference between products that survive and products that fail.
We rebuilt PathPro because our own tools showed us exactly what our users wanted and what they did not want. We did not guess. We did not run hypothetical exercises. We collected real feedback from real users, let them vote on priorities, analyzed the patterns, and built accordingly.
The result is a product that feels focused instead of scattered, fast instead of bloated, and aligned with what customers actually need instead of what we assumed they would need. Every feature in PathPro today earned its place through data.
If you are building a product and you are not systematically collecting and acting on customer feedback, you are guessing. And guessing is expensive.