upselling additional co-working space products

users: co-working space members and their busy front-desk building managers, internal company business users

user problem: with very little insight into available “add-on” products, co-working space members are mostly unaware of what types of enhancements and services they could purchase in addition to their base memberships. most only request things like maintenance or IT services when there’s a problem, and the process to fulfill said requests require signed contracts and lots of handholding between members and busy front-desk building managers.

additional business problem: there was a software monolith sitting in the middle of all existing business processes, and each time the business wanted to adjust their product offerings, it would take engineering effort to update the system. the engineering directive was to break out all membership and additional products and services out into it’s own database to live and breathe on their own while still connecting to all internal business facing systems.

goals: 

• determine MVP for member-facing “add-ons”: which add-ons to start with based on current demand / average monthly revenue along with fulfillment effort required, and where to house add-ons to surface to members

• collaborate with design to establish an initial request-to-fulfillment flow including elimination of contract process and collecting fulfillment information upon request

• planning a way to create/update/archive add-ons outside of the monolith

• determining proposal processes for add-on price variants based on co-working space location

co-working space member outcomes: 

• view and request relevant, enticing add-ons

• get add-on fulfilled with little to no back-and-forth communication (no contracts or building manager handholding)

internal company business user outcomes: 

• make changes to add-on offers to experiment with new variants

• finance & legal can approve/deny offering requests and ensure approved requests track revenue data accurately

lessons learned:

• without dedicated PMs on development teams, ownership and responsibility of backlog items should be delegated clearly

• sometimes it’s worth it to slow down a little to reflect and examine processes, in an effort to speed up later