Background
We’re building cloud-sync right now, and many people have also asked for the ability to share pools. It’s complex enough that we probably won’t get it perfect on the first try.
In the interest of getting as close as possible, I want early feedback as we plan out this feature. I’ll start with my (current) decision, and follow-up with more context.
This is your invitation to be relentless with feedback – if this isn’t what you want, let us know… Seriously, please tell me if you prefer something else.
Decision (tentative)
Teams. If you want to share a pool, you add the people & the pools to your team. We’ll have an insanely cheap “family” plan for households, where you make a Pooldash team & add your family to it. In the future, we can introduce the ability to share subsets of pools with specific team members… but we’re not there yet.
Context
Here are the 2 main groups of users requesting this feature:
1) A family sharing their 1 pool (and sometimes a hot tub).
Currently:
They either share 1 of their phones for all pool-care (which is annoying), or they re-create the pool on each of their phones (duplicate versions of same pool with no shared history between them).
Possible approaches:
a) Family members could just share a login… but:
- This wouldn’t work on different devices if any of them used “sign in with apple”
- They wouldn’t be able to see who performed what service (does that matter?)
b) Family members could each create their own login & share individual pools with individual users
- We’d need a way to send / accept pool-share invites
- We’d have to be careful about deletes / un-sharing / etc…
- Edge-cases:
* you shared the pool but not the hot-tub
* Mom shares with Dad, Dad shares with Son, Mom unshares with Dad… what happens to Son?
c) Each family could be a “team”, where all members have full access to all pools.
- This probably requires more initial setup / mental-overhead than people really want
- It does eliminate the above edge-cases
- It makes billing easier
^^ Most people think they want b
but actually need c
, so it will be our goal to present c
in a way that aligns with their initial expectations.
2) A pool service company, with many service-technicians, managers, and pool owners.
Currently:
It’s chaotic. Techs just use this app & then manually input data into their company’s system afterwards (if that system even exists). There is a large gap between big franchises & small companies.
Possible approaches:
a) Each company would create a team plan, and every technician would have access to all pools.
b) We could have different tiers of permissions, but that would introduce a lot of complexity & customer support (ex: “Bob couldn’t see the pool because it’s added to Craig’s Tuesday route”, or “You can’t edit the volume of that pool because you’re not an admin”)… In my experience, this approach is a siren-song (sounds great, but is actually bad & will get us stuck forever).
c) We could integrate with company’s existing systems for route-management (bigger companies usually have the pool info stored in a CRM, and we should just integrate with those vs competing against them).
^^ It’s my general philosophy to start small but not work ourselves into a corner. We’ll do a
for now, and we can maaaaaybe add complexity over time (online billing, CRM integrations, etc…). However, I want to prioritize the needs of our actual current users over potential future enterprise buyers (lots of companies build for the managers, but it’s more fun to build for the workers).