Building software while figuring out what exactly to make is hard and can be very frustrating. You do not know how long the research will take, and the outcome is unclear.

And yet, your boss keeps asking:

HOW LONG IS IT GOING TO TAKE?

Here are three practical tips you can use when you are in this situation.

1: Split It Up

Separate the work into research and implementation.

Timebox the research and commit to knowing enough by the end of that period to determine one of three outcomes:

• You can plan and proceed with the work
• You need more time for further research
• It is not feasible

My manager at Microsoft HoloLens once told me:

“I do not tell you what to commit to, but I do want commitment.”

So even if someone is only asking what you are going to research, you still need some kind of plan.

And that is where tip 2 comes in.

2: Compare

Even if you have never built this exact kind of thing before, there is almost always something you can compare it to.

Maybe you have worked on a project that:

• Used the same language or technology
• Had similar complexity or scale
• Was built by the same team
• Involved similar risks
• Had similar integration challenges with external systems or APIs
• Required a similar level of testing, debugging, or performance optimization

There are many ways to draw useful comparisons but how do you come up with those reference points?

That is where tip 3 helps.

3: Imagine

If you really have no idea where to start, sit down and mentally walk through the process.

Here is an example.

I once needed to create an app to connect different Microsoft HoloLens devices in our studio in Berlin. I had no idea how to approach it.

So I started walking through the work in my head.

How would I normally start?

Create a new project. Put it in Git. Add it to the build pipeline.

But wait... what technology?

Unity? No, I do not need 3D. Then let's use XAML and C#.

How would the devices communicate? I need to figure out sockets. And which protocol do I need? TCP or UDP?

That needs research.

What should the UI look like?

Is this one-to-one communication, or a central app with multiple clients? Can every client also act as a server?

Once you start taking that journey in your head, new questions keep appearing before you have written a single line of code.

Separate those questions into research and implementation, then go back to step 1 if needed.

Bottom line

The bottom line is that when someone asks for an estimate, they are often not demanding certainty. They are asking for your current best assessment and your plan for reducing uncertainty.