Planning a B2B user conference around customer maturity
Customers at different stages of using your product want different things from the same two days, and one agenda rarely serves them all.
The short answer
Define three or four customer maturity segments from data you already hold (for example evaluating, adopting, scaling and advanced), write one outcome per segment, and build the programme as tracks that serve each outcome. Decide the mix of session types, the speakers (customers, partners, your own staff) and the shared moments before you open registration.
Roadmap content, live demos, sponsor rules and the attendee journey each have their own decisions. Link to the sibling pages for those rather than solving them inside the tracks.
Why maturity beats job title or product line
A new user needs to see how to get started and what good looks like. An advanced user wants peers, depth and a direct line to your product team.
Organising by maturity shows how much a customer already knows and what they will do with the event, which job titles alone do not tell you.
Segments and what each needs
| Segment | Who they are | What they want from the event | Session types that tend to suit |
|---|---|---|---|
| Evaluating | Prospects and trial users still deciding. | See how the product fits their situation. | Customer stories, short product overviews, open Q&A. |
| Adopting | Recently onboarded customers in first months of use. | Get live fast and avoid common mistakes. | Practical workshops, onboarding clinics, peer tables. |
| Scaling | Customers rolling out to more teams or regions. | Governance, integrations, change management. | Customer-led case sessions, architecture and roll-out sessions. |
| Advanced | Power users, admins, integration partners. | Depth, early views of changes, peer exchange. | Deep-dive sessions, product team roundtables, partner sessions. |
Decision sequence
- Pull customer data already in your systems to define maturity segments, such as length of use, modules or features in use, number of users or teams, and support tickets by type.
- Count customers per segment and estimate how many from each would attend, then decide how many sessions each track needs.
- Write one outcome per segment: what the attendee should be able to do or decide afterwards.
- Build the track grid with a shared opening and closing, and parallel sessions between. Keep at least one moment where the segments mix.
- Choose speakers for each track: customers for scaling and adopting, partners for integrations, your product team for advanced.
- Decide which sessions need customer approval of their story, and agree wording with each customer's own communications or legal contact.
- Plan registration so that attendees self-select a segment and see their track suggestions; link to the event brief builder for your own planning notes.
Questions to settle with your own team
- Which team owns each segment's content: customer success, product, marketing or partner management?
- Which customer stories are cleared for public use, and who at the customer approves them?
- Which product topics are public and which are only for named customers? See roadmap briefings versus public sessions.
- Which demos will be shown, and to whom? See demo access planning.
- How will sponsors or partners be placed so the tracks stay useful? See multi-vendor sponsor conflicts.
Common pitfalls
- A programme that is mostly product announcements, with little for customers who want to use the product better.
- Customer speakers recruited too late to clear their story internally.
- Segment labels that sound like ratings, which makes attendees avoid the first track.
- No shared moment, so advanced and new customers never meet.
Worked example · Fictional example
A fictional B2B software user conference
Fictional organisation and figures, for illustration only.
A fictional software company, Penyedia Perisian Contoh, plans a two-day user conference for about 300 attendees from customers and partners.
Customer data suggests four segments: evaluating, adopting, scaling and advanced, with expected attendance of about 40, 90, 110 and 60. The team writes an outcome for each, then builds three parallel tracks on day one (adopting, scaling and advanced) and a shared opening and closing session. Evaluating attendees join a half-day introduction track before the main programme.
Five customer stories are lined up for the scaling track, and each customer's communications contact is asked to approve the wording. Two product roadmap sessions are kept separate and open only to named customers.
Use this yourself
Customer maturity programme map
Copy one row per segment. Complete it with customer success, product and marketing before the programme is drafted.
| Segment | How we define it (data) | Expected attendees | Outcome in one sentence | Track and session types | Speakers and approvals needed | Open question and owner |
|---|---|---|---|---|---|---|
Handle it in-house, or bring in help?
Your team can usually handle this when
- One day, a single product, and a customer success team that already segments customers.
- A small number of customer speakers who are easy to clear.
- Few partners and no sponsors.
Outside planning help earns its fee when
- Several products, many segments and a mix of customer, partner and sponsor content.
- Customer stories, roadmap content and demos each need separate approvals.
- The internal team cannot hold the programme timeline alongside their day jobs.
Need someone to hold the programme build?
A conference project lead can run the segmentation and track-grid workshops with your teams, track speaker and customer-story approvals, keep the decision log and coordinate suppliers around the agreed tracks. Product, customer and legal decisions stay with your teams and advisers. Send the segment list and date to scope the work.
Questions organisers ask
How many maturity segments are enough?
Three or four. More than that creates thin tracks that are hard to staff and hard for attendees to choose.
Should new and advanced customers share sessions?
Share the opening, closing and some social moments, and keep the technical sessions separate by segment.
Who should speak, customers or our staff?
Mix both. Customer-led sessions suit scaling and adopting; staff-led sessions suit product depth. Clear customer stories with the customer first.
Do we need data to segment customers?
Some data helps. Start from what you already hold, such as length of use, modules and users, and refine with customer success judgement.
Related resources
- Separating product roadmap briefings from public conference sessions
- Planning demo access for clients, partners and competitors
- Managing sponsor conflicts at a multi-vendor technology forum
- Translating technical programme complexity into a usable attendee journey
- Event brief builder
- Outsourced conference project management
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.