Give me your problem, not a spec

I was hired into a company as their first technical and engineering hire.

The company was at an extremely early seed stage. They were set on the industry and the market they wanted to capitalize on, but they were not sure how to get there, or what to make. Everyone was still running proofs of concept for what a good business model would look like.

That is closer to normal than it sounds. It is what a new product development team faces inside a small company, and inside a huge one. You have a rough picture of what to do, and the specifics are undetermined. That was exactly the situation I was hired into.

One thing was settled. They wanted to do produce distribution. That was the canvas I worked on.

Interviewing, and why it was hard

I put a lot of emphasis on two things. Interviewing, and mocking.

Interviewing mattered most, and it was the harder of the two, because nobody had done this before. There was no reliable set of facts about the process, only a lot of guesses.

So my first question was never what they wanted me to build. It was to understand the situation we were in. Only after collecting and compiling everyone’s qualitative information did I make a proposal from my end.

That took real research on my side as well, to understand how distribution actually works and what information was missing. I never treated their words as the complete truth. There is a fine difference between believing what someone tells you, and believing that what they told you is the complete set of information you need.

Mocks during the interviews, not after

Mocking was not a step that came after interviewing. It happened during.

Asking someone vaguely what they want, or what their business is, returns the same shallow answers no matter how many interviews you schedule. There is only so much that talking can do.

So I built mock screens, and functional mocks people could actually use, so they could see what it was like to operate the system rather than describe it.

This was well before the era of AI coding, so the mocks cost a great deal of time and effort. My days were spent almost entirely on interviews, which meant I was up most nights for a month or two building the next version.

The proposal

My proposal came down to a single question. What is the foundational technology that can withstand the changes that are inevitable in this company for years to come?

That question is not specific to startups. Any new product development team goes through constant change, including inside a large company. Building everything at once, including the parts most likely to change, is how a budget gets wasted.

So I kept asking what the most foundational technology was that this company could benefit from immediately, and for years afterward.

My answer was the database. One place to store and manage all of their transactional data.

That was not the easiest proposal for my clients to hear, because it is not flashy. What I told them was that if they wanted to build something real out of their business through agricultural technology, they could not skip the step where all of the transactional data lives in one place, so it can be analyzed, reviewed, and built on top of.

This post is about how things started, so I will leave out the years in between. The decision held. That system now handles roughly $8 million a year in produce sales, and the company has accumulated years of clean transactional data, which is unusual in an industry as old-fashioned as agricultural distribution. That data is what makes the flashy work possible now, and managing it well is what allowed the company to scale.

It is ok not to know

None of this would have happened if they had handed me a finished spec.

They could not have written one, and that is fine. It is normal for a client not to know what they want built. In that situation, giving me your problem and your goal instead of a spec is the better call.

Had they pushed and written a spec themselves, it would have become a spreadsheet that partially automates whatever is in front of them today. That is not always the wrong answer. Sometimes it is exactly what a business needs. But it was not the task I was given, and more spreadsheets were never going to solve the problem they actually had.

So this is not really a story about working at a startup. Interview properly, mock things up, and propose the foundation they need. That approach works on any early stage team, at any size of company, and it beats waiting for orders.