The best place to look for a software idea is the part of your week you’d happily never do again. Not the part you find interesting. The part you find tedious, repetitive, and slightly embarrassing to explain to someone outside your company.
The catch is that you stop noticing tedium after a while. A workaround you’ve done every day for a year feels like the job, not like a problem. This exercise fixes that by making you write it down for seven working days.
The setup
Use a paper notebook, a notes app, or a single doc. The format doesn’t matter. What matters is that you log things in the moment, not from memory on Friday. Memory edits out the boring parts, and the boring parts are exactly what you’re hunting for.
Each entry gets five fields:
- What I was trying to do. “Send a follow-up after a demo,” not “admin.”
- What I actually did. Every tab, copy-paste, and lookup. Be literal.
- How long it took. A rough guess is fine.
- What annoyed me. One sentence, in your own words.
- Who else does this. Your team, your prospects, another department.
Aim for three to five entries a day. Some days you’ll log more. Don’t filter yet.
Days 1 to 5: log, don’t judge
For the first five days, your only job is writing things down. You’ll be tempted to start solving by day two. Resist it. Early solutions anchor you to the first problem you noticed rather than the best one.
Pay extra attention to these moments, because they often point at real gaps:
- You copied the same information from one tool into another.
- You kept a personal spreadsheet because the official system didn’t do what you needed.
- You asked a colleague something that should have been easy to look up.
- You did something on a schedule (every Monday, every month-end) that follows the same steps each time.
- You apologized to a customer or prospect for a delay caused by an internal process.
Log what you see from the other side of the call, too. AEs hear prospects describe their workarounds all day. CSMs watch customers fight their own processes in every QBR. Recruiters hear hiring managers complain about the same handoffs. Those count. Mark them with a different symbol so you know they came from someone else’s workflow.
Day 6: sort and score
On day six, read everything in one sitting and group similar entries. Twenty-odd scattered notes usually collapse into a handful of recurring themes.
Score each theme from 1 to 3 on four questions:
- Frequency. Does it happen daily, weekly, or a few times a quarter?
- Cost. Does it waste minutes, hours, or money and deals?
- Breadth. Is it just you, your team, or a whole role across many companies?
- Buildability. Could a small web app with a form, a database, and a few screens plausibly help, or does it need deep integrations with five enterprise systems on day one?
Add up the scores. Anything high on frequency and breadth but low on buildability goes on a “later” list. Your first product should be something you can build a useful version of in a few weeks.
Day 7: write the problem statement
Take your top one or two themes and write a short problem statement for each. Three sentences: who has the problem, what they do today, and what it costs them.
For example: “Account executives at small agencies rebuild every proposal from an old deck. It takes a couple of hours each time, and pricing gets copied wrong. Approvals happen over email and get lost.”
Notice what isn’t in there. No product name, no features, no “AI-powered platform.” A problem statement that already describes the solution is a pitch, and you’re not ready to pitch yet.
What to do with the result
You now have one or two written problems grounded in real, logged moments. That’s more than many products start with. The next step is checking whether people beyond your own desk feel the same pain, which means conversations, not code.
BLDR Lite covers that next step for free: turning a logged problem into a short list of people to talk to and the questions to ask them.