Share the thing you’re still figuring out

You don’t have to wait until a feature is finished to talk about it. Share the decision you’re stuck on while someone can still help you think it through.

Maybe you’re changing your onboarding. Maybe you’re trying to decide what belongs in the free plan. Maybe a customer asked for something that sounds simple, and now you’re three days into figuring out how to build it.

That’s worth talking about too.

It’s easy to understand why the finished stuff gets posted. You have a screenshot, a working feature, something you can point to and say “shipped.” It feels good to share that. And when you’ve been working on something for a while, getting a few “nice work” replies is encouraging.

But there’s a lot going on before that screenshot. You’re choosing what to build, what to leave out, and what can wait. Those decisions give other builders something useful to discuss with you.

Give people enough to work with

Say you’re building a scheduling app for freelancers, and you’re working on signup.

You need users to connect their calendar eventually. You’re unsure whether to ask for that immediately or let them look around first.

You could post a screenshot and write “working on onboarding, thoughts?”

Someone reading that has to figure out what kind of feedback you want. They might comment on the colors when you’re actually worried about asking for calendar access too early.

Try explaining the actual decision:

Working on signup for a scheduling app.

Trying to decide when to ask people to connect their calendar. If we do it right away, they can see their real availability. If we wait, they can explore first.

Thinking of starting with a sample calendar and asking them to connect theirs when they create a booking page.

Anyone tried something similar?

It’s a simple post. You’ve explained what you’re building, where you’re stuck, and what you’re considering.

Someone who’s worked on a similar flow can tell you what happened. Someone who uses scheduling tools can explain what would make them hesitate. You might even get a question that makes you realize you’ve been focusing on the wrong part.

There’s room for an actual conversation.

Include the annoying detail

The detail that makes a decision difficult is usually worth including.

You only have a few days before launch. You’re maintaining the product yourself. A customer needs something urgently, but you’re halfway through another feature.

Without that context, someone can give you advice that sounds reasonable and would be difficult for you to use.

Take team accounts as an example.

“Should we add team accounts?” is a pretty broad question. There are a lot of possible answers, depending on the product and who uses it.

Now imagine the situation is this:

Two customers have asked for team accounts. Building it means adding permissions and changing billing. That would push back the reporting update they’re already waiting for.

Trying to work out whether shared access would be enough for now.

That gives someone much more to respond to. They can ask what the customers actually need to do together. Maybe they only want a colleague to view a report. Maybe they need separate roles and approval steps. Those lead to very different amounts of work.

Writing out the situation also gives you a chance to catch your own assumptions. You might notice that you’ve already decided how to build something before you’ve properly understood the request.

You can share something unfinished

Posting an open decision can feel a little uncomfortable. You’re letting people see that you haven’t figured it out yet.

But you can explain where your thinking is at without turning it into a big personal story.

“Still deciding how this should work” is enough.

You also get to choose what you share. Leave out customer names, private conversations, and anything you’re uncomfortable putting in public. You can describe the problem in general terms and still give people enough context to be helpful.

And you don’t have to post every decision. If writing an update starts taking longer than working through the problem, keep it smaller. A paragraph and a screenshot might do the job.

When replies come in, take a little time to understand where the advice is coming from. Someone building for large companies may have different requirements from someone selling to solo freelancers. Both can have useful things to say, but you’ll need to work out which parts fit your situation.

You’re still the person making the decision. A suggestion in the comments doesn’t have to become another item on your roadmap.

Then, once you’ve chosen, come back and tell people what you did.

For the scheduling example, you could explain that you went with a sample calendar, what made you choose it, and what you’re watching now. You might still be unsure whether people understand the next step. That’s fine to say.

If someone’s reply helped, thank them. If you tried their suggestion and it didn’t work for your product, explain what happened. That gives them something useful back too.

There’s plenty to share while you’re building. The feature you shipped is one part of it. The question that held you up for two days can be worth a post of its own.

So if you’re looking at your product right now and trying to decide what to do next, start there. Explain what’s making the choice difficult and let a few other builders think it through with you.

What are you figuring out this week?