How we whittled a product idea to its simplest form

This is the sketch we started with. I made it based on Connor’s written and verbal description of a fuzzy idea he had while talking to ecological landscapers.

Cool! The design phase is done, right? I mean, the whole app is only 2 pages and an automated text message. How hard can that be to build?

As we often remind clients, the simplicity at this stage is a mirage. No matter how small an app sketch or mockup is, there are always more features than you think. And for each feature, there are a handful of technical and UX questions whose answers can conflict with one another and create additional features and complexity.

Let’s walk through the sketch. There are a surprising amount of features here.

First, the explicit features (the ones you can see):

1. Accept SMS from client
2. Accept MMS from client
3. View record (aggregate messages from all clients of a record)
4. View client message history
5. Send manual SMS to clients
6. Send automated SMS to clients once a month

Then, the implicit features:

1. Auth (sign up and login)
2. Create record
3. Edit record
4. Delete record
5. Create client
6. Edit client
7. Delete client
8. Associate record(s) with client(s)
9. Dissociate record(s) with client(s)
10. Manage LandscapeMate phone numbers

Now, for each of these 16 features, there are design (both technical and UX) questions that should be answered before we start building. Take, for example, the feature “send automated SMS to clients once a month.”

1. Do clients need to opt-in?
2. Can clients opt out? Can they opt back in?
3. If a client opts out, can they still send and receive manual messages with the phone number?
4. Is there an initial onboarding text?
5. What should it say?
6. Can it be edited? If so, what happens?
7. Can it be turned off? If so, what happens?
8. What is the cadence (day, time, frequency) of automated reminders?
9. What should it say?
10. Can it be edited? If so, what happens?
11. Can it be turned off? If so, what happens?
12. If a client is associated with multiple records, should they get multiple automated reminders or just one?
13. Should we automatically reply to client messages (something like “thanks, got it!”)?

Needless to say, our “tiny” sketch turned out to be bigger than we hoped.

So we did a collaborative design sesh in FigJam to explore ways to shrink the first feature set while still delivering enough value to get a couple of real users.

With a few strategic (albeit tough) decisions, we realized we could avoid a lot of complexity and save time during the build phase.

1. No organization account, just user accounts. If we get one person using this who wants to add their colleague, we will recommend they share a login and then build the feature into the app. That said, we architected the backend to be able to easily have this feature in the future.
2. Clients can only be associated with one record. This eliminates a lot of technical complexity. Plus, we aren’t sure landscapers even want to add multiple clients per record.
3. No ability to text clients back. This was the toughest tradeoff. We figured while yes, it will be awkward for landscapers to not be able to reply to messages they receive, the app will technically still do its job of automatically collecting site photos. Saving some build time to get feedback quicker is worth the risk.
4. No distinction between records and chats. Since there’s no ability to text clients back, there’s no need for an individual client view. All we need is a record that accepts MMS and SMS messages from clients.
5. No ability to edit automated messages or their cadence. We’ll explain that we configured messages to collect site photos regularly while not bothering clients too much. We expect this will be an issue for users, but we think we might be able to achieve our value without these features initially.

Now the question becomes: Did we choose the right features to eliminate and simplify? Are ecological landscapers going to feel comfortable using such a simple service? The only way to find out is to demo with potential users. If we discover that folks won’t sign up because it’s missing a feature we removed, that’s great! We can build it. But we believe iteratively adding features to a dead-simple foundation is a more effective (and faster) path to creating usable products than trying to push a big complex app in the right direction.