The First Version of Your Product Includes You

At Estateflow, we can create deal stages, properties, and workflows for a client with one click.

Then we have to make sure the setup fits the team that will use it.

Some clients have a setter who handles appointments. Others don’t. Some have more employees, or need a particular rotation for assigning work. Despite our efforts to standardize, those differences still need attention. We accommodate them manually and check that everything is configured correctly.

The one-click part is useful. It just has a shorter job description than we do.

Estateflow is deliberately a service. We set up the flow, campaigns, and website, connect HubSpot and Aircall, and configure event tracking. Our technology helps us do that faster. We still check the result and fix the things the automation doesn’t handle properly.

That work is part of what we offer. A customer needs a setup that works for their business, including the details that don’t fit our standard configuration.

When I think about what we’re building, I have to count that work too. The customer’s experience includes the application, the configuration, the checks, and the adjustments. Some of those happen in code. Some happen because we’re there.

Before we brought parts of this into our own application, we configured a Zapier workflow for each client. It took time to see which patterns repeated often enough to bring in-house.

That sequence matters. Working through individual setups gave us something concrete to compare. We could see where the same work kept coming back and where clients needed different arrangements. The repeated patterns gave us a basis for deciding what belonged in our application.

With Zaplink, I also offered the setup before there was a platform. I did the integrations myself and eventually built the system.

In both cases, the work existed before all the software did. Delivering it gave us a way to discover what could become software.

There is useful information in that gap. A feature request might ask for assignment rules. Setting up the workflow requires knowing who is available to take the work, whether someone else handles appointments, and how the team rotates responsibility. Those details determine whether the configuration makes sense.

But being involved also makes it possible to miss a different kind of problem.

If you guide a customer through every step, they may get a good result from software they couldn’t have navigated alone. You explain the unfamiliar label, supply the missing context, and steer them away from the confusing option. The session goes well. How much of that success belongs to the interface?

A founder can be a very effective help button. The trouble starts when that button needs dinner.

For a product intended to be self-service, repeated explanations deserve investigation. For a service like Estateflow, setup and verification can remain part of the offer. Even then, it’s worth asking how much of the work depends on one person’s memory and availability. Human involvement can be valuable without every task needing the founder personally.

That leaves a practical question: how do you decide what to do with the work you’re doing around the product?

Here are four questions worth applying to a real customer interaction. They can lead to different answers for different parts of the same setup.

1. Am I still learning something that affects what we should deliver?

   Keep doing the work personally when it helps you understand an unfamiliar problem. Pay attention to the decisions you have to make and the information you need to make them. Estateflow’s differences in team structure are a concrete example: a setup has to accommodate how responsibility is actually assigned. Repeating a task a few times doesn’t necessarily mean you understand all the decisions inside it.

2. Could someone else follow a clear process?

   Document a useful process once it starts repeating. Include what to check, how to recognize a correct result, and when to ask for help. A list of clicks is less useful if the next person can’t tell whether the setup works. Documentation can make delivery more reliable while leaving room for judgment.

3. Do we understand this well enough for software to handle it?

   Automate when the process is understood and repetition is consuming time. Be specific about which part is stable. At Estateflow, repeated patterns across client workflows eventually justified moving functionality into our own application. That still leaves configuration differences and exceptions for us to handle. You can automate a well-understood portion without solving every variation first.

4. Why does the customer keep needing this explanation or rescue?

   Investigate before making the workaround more efficient. If people repeatedly misunderstand a step, another tutorial might leave the underlying confusion intact. The wording, sequence, or default may need to change. If the difficulty comes from a real difference in the customer’s business, the answer may be a configurable option or deliberate help from a person. Similar-looking support requests can have different causes.

You can combine these approaches. A process can be documented and still require judgment. An automated setup can still deserve a human check. The useful decision is about the particular work in front of you.

To try this, review your last five customer interactions. For each one, write down what you had to do, why it was necessary, whether it has happened before, and what should happen next.

Then choose one improvement. It could be a checklist someone else can follow, an import you can automate, a confusing step you can change, or a part of the work you deliberately keep doing because you’re still learning from it.

At Estateflow, the one-click setup hasn’t made those differences between clients disappear. It has changed which parts of the work we need to do ourselves.

Your first version includes you. Looking closely at what you’re contributing can help you decide what the next version needs.

Think about the last customer you helped: what did you have to do that the product couldn’t, and what should happen the next time?