Should a SaaS features page follow the product's architecture or the customer's journey?

Follow the customer's journey. Group the features on a SaaS features page by what the customer is trying to do, from getting started to the wider benefit, rather than by the modules, settings and roadmap categories your team uses: buyers recognise their own situation, and next quarter's feature has an obvious place to go. Inside the product the answer changes, because navigation should follow the records and tasks people work with every day. Neither the page nor the product should be organised around the codebase.

Why features pages end up shaped like the product

At Tcules, we discussed this with conversion copywriter Alex Napier Holland in season 1, episode 2 of our podcast, Beyond the Interface, published on 1 May 2025. He described where the problem starts: "A lot of the time developers create a product road map and they create categories for their features, and those categories reflect the way that a developer views the architecture of a product, and that could have absolutely nothing to do with how a customer sees it." (1:10:52)

The team that builds a product knows it as a set of parts: projects, automations, reports, permissions, integrations. Where the roadmap is planned in those parts and the work divided along them, they easily become the natural headings for a features page. A buyer arrives with a different question: will this help with the thing I am trying to get done? That is the idea behind jobs to be done, which Clayton Christensen and colleagues summarised in Harvard Business Review in September 2016: what matters is "the progress that the customer is trying to make in a given circumstance". The Christensen Institute describes a job as the progress someone is trying to make towards a goal within particular circumstances. A list of modules describes the product. It does not describe the progress.

Three public features pages show the range (illustrative only; checked 16 October 2026):

• Asana's features page groups by capability area: AI features first, then Project management, Goals and reporting, Workflows and automation, Resource management, Admin and security, Integrations.
• Freshdesk's features page writes benefit headlines over capability groups. "Automate everything repetitive" sits above ticket dispatch, automations, multiple SLA policies and two kinds of ticket assignment, under the group Routing and SLA. The headline speaks to the buyer; the grouping underneath is still the product's.
• Jira's features page leads with four stages of running a project, Plan, Track, Collaborate and Report, under headings such as "Kick-off your next project" and "Stay on schedule". AI, administration and integrations follow in sections of their own.

Capability grouping is not always wrong. Where buyers shop a mature category with a shared checklist, capability names can be the buyer's own words: a support lead comparing help desks knows what ticketing and SLA policies are. In our view the real question is whose words and whose order the page uses, and whether that order still makes sense to someone who has never seen your roadmap.

Group features by the stages of the customer's journey

The method he described starts with customers, not with the feature list. He talks to customers about how they use the product, takes all of the features and puts them "into a series of steps that reflect the user journey" (1:10:48). The example buckets he gave (1:11:22) were:

1. Get started and get onboarded.
2. Start using the product and do the task you expected to do each day.
3. Get tactical benefits, because you can see what is going on in your company better.
4. Gain strategic benefits: grow and scale faster because of those tactical insights.
5. Expand, for example into new markets.

He described it as a journey that takes people "from fixing their initial problem to unlocking levels of growth that they didn't think were possible" (1:11:51). Treat his five as an example rather than a template; he said the buckets "might be" these. Yours should come from what your customers say they do and expect to get out of the product.

He framed this as content architecture, an expression he said "needs to be used more" (1:07:44). The story and its order come first and the layout serves them, rather than a designer creating a structure and handing it to a copywriter "to add words". For a startup page, his structure is a sequence: a hero section, a pain-point section, the solution, then features and benefits as three, four or five steps, then a call to action (1:08:23). The designer can interpret each of those sections and play with the layout, he said (1:08:56), but "you don't take chapter four and put it behind chapter two" (1:09:12). For a features page, that makes the order of the groups the decision, and the layout of each group the designer's. A buyer should meet the groups in the order they would live them.

The test: where would next quarter's feature go?

His test for a content architecture is to look at the client's site a year later (1:09:58). What he wants to see: "they've kept my content architecture and they've added a few new features, but they haven't had to redo the page" (1:10:31). When a product adds features six or 12 months on, the team should "clearly see which bucket the new feature belongs into" (1:12:00). A complete pivot is the exception; it may need a new content architecture.

That is a better test than whether the page looks clean, and you can run it on paper before anything is redesigned:

1. List the features from your last three releases and the items on next quarter's roadmap.
2. Place each one in a group on your current features page.
3. For each, ask two questions. Does it fit an existing group without a new section? Would a customer have put it there?

If new features keep needing new sections, the groups are probably named after parts of the product, and every release adds a part. If they fit but a customer would put them somewhere else, the groups follow the team's view of the product.

The second question needs customers, not a meeting. Two methods published by government digital teams fit it:

• A card sort. Give customers one card per feature, described in plain words, and ask them to group the cards. In an open sort they also name the groups, which shows their language; in a closed sort they place the cards in groups you supply, which tests your groups. The GOV.UK user research team moved to an open card sort so that users "could make categories and name them using their own language", then found that an open sort over a broad set of concepts gave patterns too weak to act on, and concluded that strong patterns need a narrower set and a closed sort, later in the process. A features list is a narrow set, and asking where next quarter's feature belongs among your existing groups is a closed sort.
• A tree test. Once you have proposed groups, give people tasks and see where they look. A team at the Office of Natural Resources Revenue, writing on Digital.gov in January 2022, ran a tree test after its card sort to confirm that subcategories sat in the right main categories, and limited it to 10 tasks because people learn the categories quickly.

Inside the product, organise around the work

At Tcules, we design the information architecture of software products, and the same failure can appear there: navigation that mirrors how the product was built. The fix is not to copy the marketing journey into the menus. A buyer reads a features page once, in order, to decide. A user comes back every day to the same records, in a particular role, to act on them. Navigation organised as "get started", "daily use" and "grow" would scatter one customer record across several stages, and a "get started" section matters little once someone has started.

Our Information Architecture and Workflow Design work starts from the product model instead: the objects that persist, how they relate, who can act on them, and the rules, states and exceptions around them. Navigation follows this model; it should not become the model by accident. We judge the architecture by whether representative roles can predict where an object belongs, what happened, what they can do next and how to recover. That is also why our product-model workshop is not a card sort.

The roadmap matters here too. In the episode I replied that when we do information architecture for a product, we want it to be scalable, because the roadmap will add features: "Some of them are going to be at the navigation level. Some of them are going to be tucked away in the second or third layer" (1:12:24). He compared it to building a house with the land and space to add bedrooms later (1:12:55).

The product version of the test is similar. For next quarter's feature, ask which object it acts on and which role uses it. If you can answer, its place mostly follows: with that object, at a depth that matches how often that role needs it. If the only answer is "it is a new module", the team is describing the codebase. A tree test with representative tasks then shows whether people look for it where you put it. If the product is already live, a structural change also disturbs paths people have learned; we cover how to stage that in how to redesign a live SaaS product without losing users.

The two tests side by side

The features page sells the journey. The product is organised around the work. If either one's structure has to change every time engineering ships something, it is following the codebase.