Title : "Features We Deliberately Didn't Build: Product Principles"

Description: "See which features MeetWho deliberately didn't build and the product principles behind privacy-first, relevant and meaningful event networking decisions."

Features We Deliberately Didn't Build: Product Principles for Better Event Networking

Features We Deliberately Didn't Build can reveal more about a product than its longest feature list. At MeetWho, several seemingly obvious networking features are intentionally absent because they would undermine participant privacy, relevance or meaningful connection. These decisions reflect a simple product principle: event networking should help people know who to meet—not expose everyone to everyone.

Why “What We Didn't Build” Is a Product Principle

A deliberate non-feature is different from an unfinished feature. It is not something sitting indefinitely in a backlog because the team lacked time to build it. It is a capability the product could plausibly offer, but chooses not to because doing so would conflict with the experience, incentives or boundaries the product is designed to protect.

That distinction matters because product principles only become useful when they influence difficult decisions. Statements such as “we care about users” or “privacy matters” are easy to agree with. A principle becomes meaningful when it causes a team to reject a feature that might increase usage, make a sales conversation easier or look impressive on a comparison page.

Every Feature Creates an Incentive

Products do more than give people tools. They also influence what users are encouraged to do with those tools. A public participant directory encourages browsing. Unlimited outreach encourages volume. Visible connection counts can turn professional relationships into something to accumulate rather than something to understand.

None of those patterns is inherently wrong in every product. The important question is whether the behaviour a feature encourages supports the outcome that particular product exists to create. MeetWho is built around a narrower objective: help participants identify the people most relevant to them and understand why a conversation could be mutually useful.

A Roadmap Is Also a List of Things You Say No To

A product roadmap usually shows what a team plans to build. It rarely shows the ideas the team deliberately rejected. Yet those decisions can be just as important because every additional capability changes the boundaries of the product.

For MeetWho, the question is not simply, “Would someone use this feature?” It is also, “Would this feature help people build better professional relationships while respecting the choices of everyone involved?” A useful product principle must sometimes produce the answer no.

A product principle becomes meaningful when it causes a team to reject something users could plausibly ask for.

Product Principle #1: We Didn't Build a Public Attendee Directory

A complete attendee directory sounds like an obvious networking feature. Put every registered participant on one screen, add search and filters, and let people work out who they want to contact. The problem is that this approach can simply transfer the networking problem back to the attendee.

At a conference, workshop or community event with many participants, seeing more profiles does not necessarily tell someone who is relevant. The participant still has to scan names, interpret job titles, compare interests and guess whether another person is looking for the same kind of conversation.

Why More Profiles Don't Necessarily Create Better Networking

A large directory provides access to information, but meaningful networking requires context. Someone may want to meet potential collaborators, customers, investors, mentors or people working on a specific problem. Another attendee may be able to help, but that connection is difficult to recognise from a name and company alone.

MeetWho approaches discovery differently. Participants can describe what they are working on, what they are looking for, who they want to meet and where they can help others. MeetWho analyses that information alongside event goals and shared interests to recommend relevant people from among participants whose networking permissions allow them to be considered.

What MeetWho Does Instead: Ranked, Explained Introductions

Rather than making every attendee browse an unrestricted public participant list, MeetWho provides personalised recommendations. Those recommendations are designed to explain not only who may be relevant, but why the two people may benefit from meeting, how they might help one another and how a useful conversation could begin.

This is an important distinction in Event Networking Intelligence. The product is not trying to maximise the number of profiles a participant can inspect. It is trying to reduce the work required to identify promising conversations.

The Product Principle

Reduce discovery work without removing participant control.

Product Principle #2: We Didn't Make Registration Equal Public Discoverability

Registering for an event and agreeing to be discoverable for networking are two different decisions. Someone may want to attend a workshop, receive event information or join an online session without automatically making their professional profile visible to every other participant.

MeetWho therefore treats event participation and networking visibility separately. Organiser settings define how networking operates within an event, while participant permission remains central to whether a person can be included in relevant networking experiences.

Event Registration and Networking Consent Are Different Decisions

This separation protects an important form of user agency. Clicking “register” should not silently create an additional assumption that a participant wants unrestricted professional exposure. The networking experience should operate within the boundaries established by the organiser and the choices made by each participant.

That principle also changes how discovery is designed. MeetWho does not need to expose everybody to everybody in order to help people find relevant connections. Recommendations can be useful precisely because they operate among participants who are eligible to participate in networking.

Privacy Should Be a Product Behaviour, Not Just a Policy Page

Participant privacy is most meaningful when it affects what the product actually allows users to do. A privacy statement may explain policies, but product architecture determines whether those boundaries remain visible during everyday use.

For MeetWho, privacy therefore influences networking discovery itself: organiser controls and participant permission take priority over the desire to maximise discoverability.

The Product Principle

Participation in an event should not silently become permission for unrestricted networking exposure.

Product Principle #3: We Didn't Sell Access to Hidden Profiles or Private Contact Details

A paid networking product could take a simple monetisation shortcut: charge users for access to more people. That might mean revealing profiles that would otherwise remain hidden, exposing contact details or giving subscribers broader access than other participants intended. MeetWho deliberately does not use that model.

MeetWho Plus improves the tools available to the person paying for the subscription; it does not weaken another participant's privacy. A Plus membership does not unlock hidden profiles or private contact information. The distinction matters because participant privacy should remain meaningful regardless of another user's willingness to pay.

Why Privacy Cannot Become a Premium Shortcut

Consent stops functioning as a real boundary if somebody else can purchase their way around it. A participant who chooses not to be visible should not become visible because another attendee upgrades. Likewise, private contact information should not become a premium database for prospecting.

This principle separates personal productivity from privileged access. MeetWho can help a user make better use of the networking opportunities legitimately available to them without changing another person's permissions. Monetisation improves the networking workflow, not the subscriber's entitlement to other people's information.

What Paid Networking Should Improve Instead

MeetWho Plus is designed around better personal networking tools. Depending on the feature, that can include more active recommendations, more detailed reasoning about why a connection may be relevant, personalised conversation starters, AI-assisted introduction and follow-up messages, unlimited private notes and reminders, calendar integrations and other advanced networking capabilities.

These tools help a participant prepare, connect and follow up more effectively. They enhance what the subscriber can do with their own networking process while leaving other participants' privacy choices intact.

The Product Principle

Pay for better networking tools, not privileged access to someone else's privacy.

Product Principle #4: We Didn't Optimise Networking Around Connection Count

It is easy to measure networking by volume. How many profiles did someone view? How many requests did they send? How many new connections did they collect? Those numbers are visible and easy to compare, but they are not necessarily the outcome MeetWho is designed to optimise.

MeetWho's guiding idea is expressed in three words: Know who to meet. The goal is not to help someone interact with the largest possible number of attendees. It is to help them identify the people with whom a conversation has a plausible reason to exist.

Meaningful Networking Needs Mutual Relevance

A useful professional introduction should provide more than proximity. Two people being present at the same event is not, by itself, a reason for them to meet. Their goals, interests, current work and ability to help each other provide richer context.

That is why a useful recommendation should answer practical questions: Why might these two people benefit from speaking? What could each person contribute? What could they discuss first? When those answers are clear, the participant can make a more informed decision about whether to connect.

Context Is More Useful Than a Match Score Alone

A ranking can direct attention, but an unexplained score leaves the participant to interpret its meaning. MeetWho therefore focuses on explained recommendations, showing the reasoning behind a suggested introduction and, where relevant, providing personalised ways to start the conversation.

This does not require users to understand a proprietary matching formula. The important part is that a recommendation gives enough context for a human to decide whether the meeting makes sense.

The Product Principle

Recommendation systems should help users make decisions, not merely produce rankings.

Product Principle #5: We Didn't Turn Event Networking Into Unrestricted Cold Outreach

Discovering a relevant participant should not automatically create the ability to send that person unlimited unsolicited messages. MeetWho separates recommendation, connection and communication so that identifying someone as potentially relevant does not erase the need for reciprocal interest.

Users can send a connection request when they want to meet. Messaging becomes available after a mutual connection is established. This creates a deliberate step between “this person may be relevant” and “we now have permission to start a direct conversation.”

Why Mutual Connection Changes the Interaction

Mutual connection does not guarantee that every exchange will be valuable, but it introduces a meaningful signal: both people have chosen to establish the connection. That is different from treating every recommended participant as an immediately reachable prospect.

The approach also fits MeetWho's wider product philosophy. Networking should support intentional professional relationships rather than encourage users to maximise outreach simply because the software makes it possible.

From Introduction to Follow-Up

A useful networking experience also continues after two people discover each other. MeetWho supports a progression from recommendation to connection request, mutual connection and messaging, followed by private notes, follow-up reminders and post-event connection history.

The result is a workflow designed around relationship continuity rather than a single moment of discovery.

The Product Principle

A useful networking system should support relationships without manufacturing unsolicited access.

What We Didn't Build vs What We Built Instead

What We Built Instead: Event Networking Intelligence

Rejecting certain features only makes sense if the underlying user need is still solved. MeetWho does not remove participant discovery, communication or event management from the experience. It approaches those needs through a different product model: Event Networking Intelligence.

MeetWho combines event creation, participant management and personalised professional networking in one SaaS platform. Organisers can manage the operational side of an event while participants receive networking support designed around relevance, context and permission. The objective is not to make every attendee visible to every other attendee, but to help the right people identify each other when networking settings and participant choices allow it.

For Event Organisers

Organisers can create an event page on MeetWho for free and collect participant registrations through the platform. They can review and approve applications, manage waiting lists, send announcements and reminders, and share online-event links only with registered participants.

For in-person events, organisers can also use QR-based check-in. Networking privacy settings remain part of the event configuration, allowing organisers to determine how networking operates while preserving the importance of participant permission.

This brings event operations and networking into the same environment. Instead of treating networking as a separate attendee directory added after registration, MeetWho can support the journey from registration through attendance and relevant introductions.

For Participants

Participants build professional profiles that provide more useful networking context than a name and job title alone. They can describe what they are working on, what they are looking for, the kinds of people they want to meet and the areas where they may be able to help others.

MeetWho uses this information together with event goals and shared interests to identify relevant networking opportunities among eligible participants. Recommendations can explain why two people may benefit from meeting, what mutual value could exist and how a conversation might begin.

After discovering someone relevant, a participant can send a connection request. When the connection becomes mutual, the two people can message each other. Participants can also keep private notes, set follow-up reminders and manage their connection history after the event.

Free Participation vs Plus Networking Tools

Participants can join events on MeetWho using the free plan and receive a limited number of personalised introductions. Organisers can also use event creation and core event-management capabilities for free.

MeetWho Plus expands the participant's personal networking toolkit rather than providing privileged access to other people's data. It can include more active recommendations, more detailed match explanations, personalised conversation starters, AI-assisted introduction and follow-up messages, unlimited notes and reminders, calendar integrations and other advanced personal networking capabilities.

The distinction reflects the same principle described throughout this article: paid functionality should make your own networking process more effective, not make somebody else's privacy less effective.

A Framework for Deciding Which Features Not to Build

The idea behind Features We Deliberately Didn't Build extends beyond event technology. Product teams in almost any SaaS category can benefit from examining not only whether a feature is technically possible or commercially attractive, but also what behaviour it introduces into the product.

A useful feature-review process should test the proposed capability against the outcome the product exists to create. The following questions can help teams distinguish genuine user value from functionality that merely adds activity, complexity or surface area.

Question 1: What Behaviour Would This Feature Incentivise?

Every feature makes some actions easier than others. Before approving it, ask what users are likely to do more often once the feature exists.

A participant directory, for example, makes browsing easier. Unlimited outreach makes sending more messages easier. Those effects may be desirable in some products, but they should be intentional rather than accidental.

Question 2: Who Benefits—and Who Pays the Hidden Cost?

A feature can create value for one user while creating friction for another. Greater discoverability may help somebody searching for contacts while making another participant feel overexposed. Easier outreach may help the sender while increasing unwanted communication for recipients.

Evaluating both sides prevents product teams from treating the most visible beneficiary as the only stakeholder.

Question 3: Does It Strengthen or Weaken User Agency?

Good product decisions preserve meaningful choices. If a user selects a privacy preference, a new feature should not quietly make that preference irrelevant.

This test becomes especially important when monetisation is involved. One customer's upgrade should not remove another person's ability to control their own visibility or private information.

Question 4: Would We Still Build It If It Increased Engagement?

Engagement is useful only when the activity reflects the outcome the product is meant to create. A feature may increase profile views, messages or time spent in an interface without improving the quality of the user's result.

For networking, more interactions are not automatically better interactions. A product principle helps teams resist optimising a measurable proxy when it conflicts with the real objective.

Question 5: Can We Solve the Underlying Need Differently?

Feature requests often describe a proposed solution rather than the underlying problem. “Give me every attendee profile” may actually mean, “Help me find the people relevant to me.”

That distinction creates room for better product design. MeetWho's response is a useful example: instead of solving discovery by maximising access to profiles, it uses personalised recommendations to reduce the effort required to find promising conversations.

The Features-We-Don't-Build Checklist

Before approving a feature, product teams can ask:

• Does it improve the user's intended outcome?
• What behaviour does it incentivise?
• Does it expose information users reasonably expect to control?
• Does it reward quantity over relevance?
• Does it create unsolicited access?
• Can the same need be solved with greater user agency?
• Does monetisation alter another person's privacy?
• Can users understand why the system made a recommendation?
• Does it reinforce the product's core promise?
• Would we be comfortable explaining publicly why it exists?

The Bigger Product Principle: Build for Outcomes, Not Feature Count

Deliberately refusing to build a feature is not the same as pursuing minimalism for its own sake. A product can be feature-rich and still remain coherent if every capability supports the outcome it exists to create. The harder question is whether each new feature strengthens that outcome or quietly pulls the product in another direction.

For MeetWho, that outcome is not maximum visibility, maximum outreach or maximum connection volume. It is helping participants identify relevant people, understand why a conversation may be worthwhile and build professional relationships within clear privacy and consent boundaries. That is the logic connecting every decision in this article.

Know Who to Meet

Know who to meet is more than a slogan. For organisers, it means creating an environment where networking is useful without turning event registration into unrestricted participant exposure. For attendees, it means spending less time scanning lists and more time evaluating relevant introductions.

The same principle also shapes what happens after discovery. Recommendations should provide context. Connection should involve mutual intent. Messaging should follow connection. Notes, reminders and connection history should help participants continue relationships after the event rather than treating networking as a one-time interaction.

Sometimes the Best Feature Decision Is “No”

A product team can always add another filter, another growth mechanic, another data surface or another reason to upgrade. The existence of a possible feature, however, does not make that feature compatible with the product's purpose.

The strongest product principles are visible precisely when they constrain the roadmap. For MeetWho, saying no to unrestricted attendee directories, privacy-bypassing premium access and connection-count optimisation makes room for a different kind of product: one centred on relevance, explanation, mutual value and participant control.

Know Who to Meet—Not Just Who's Attending

MeetWho combines free event creation, participant registration and management with intelligent networking designed to help attendees discover more relevant people. Organisers can manage registrations, approvals, waitlists, communications, QR check-in and networking privacy settings from the same platform.

Participants can build professional profiles, receive personalised introductions, understand why someone may be worth meeting, connect with mutual intent and keep track of follow-ups after the event.

Create an event for free with MeetWho and give participants a better answer to one of the most important questions at any professional event: who should I meet?

Explore MeetWho

Frequently Asked Questions About Product Principles and MeetWho

What does “Features We Deliberately Didn't Build” mean?

Features We Deliberately Didn't Build refers to capabilities a product team intentionally chooses not to offer because they conflict with the product's principles, user interests or desired outcomes. These are different from unfinished features or backlog items. A deliberate non-feature represents a conscious product decision about what the experience should—and should not—encourage.

Why would a SaaS company deliberately avoid building a requested feature?

A requested feature can still create undesirable incentives, weaken user agency, introduce privacy trade-offs or optimise a metric that does not reflect the user's real goal. Product teams should evaluate not only whether people would use a feature, but also how it would change behaviour and whether another solution could meet the underlying need more effectively.

Does MeetWho show a public list of every event attendee?

No. MeetWho does not rely on an unrestricted public attendee directory as its networking model. Instead, it recommends relevant people among participants who are eligible for networking based on organiser settings and participant permission, using professional profile information, goals, interests and event context to make discovery more useful.

Can MeetWho Plus users see hidden profiles or private contact information?

No. MeetWho Plus does not override participant privacy, reveal hidden profiles or provide access to private contact information. Plus is designed to improve the subscriber's own networking workflow through features such as more active recommendations, richer match explanations, conversation support, notes, reminders, calendar integrations and other advanced networking tools.

How does MeetWho recommend people to meet?

MeetWho considers information participants provide about their professional context, including what they are working on, what they are looking for, who they want to meet and how they may be able to help others. Shared interests and event goals can also contribute to the context used to recommend relevant people among participants whose networking permissions allow it.

Can organisers control networking privacy?

Yes. Networking privacy is influenced by organiser settings as well as participant permission. Organisers can configure how networking works within an event, while participant choices remain central to whether someone is included in networking discovery. Event registration alone is not treated as unrestricted consent to be publicly discoverable.

Can organisers create events on MeetWho for free?

Yes. Organisers can create event pages on MeetWho for free and use core event-management capabilities such as registration collection, application approval, waitlist management, announcements, reminders, online-event link sharing for registered participants and QR-based check-in.

What is Event Networking Intelligence?

Event Networking Intelligence is MeetWho's positioning for a model that combines event management with personalised professional networking. Instead of treating networking as access to a long attendee list, the approach focuses on identifying relevant people, explaining why a meeting may be useful and supporting the relationship from introduction through follow-up.

The most important product decision is not always what to add next. Sometimes it is deciding which behaviours a product should refuse to create. For MeetWho, that means building toward one clear outcome: helping people make fewer random connections and more relevant, mutually useful ones.