Balsamiq: a colleague's problem, made concrete

Where the story begins

In his 2008 founding account, Peldi described a product manager who understood how an interface should work but lacked time to learn complex design software. That frustration led him toward a simpler mockup tool. Early development happened alongside his job, with a Confluence plugin among the initial ideas. Balsamiq's company page still describes the business as independent and bootstrapped.

This is an editorial reading of public sources, not an interview. The observations below are ours, not a method endorsed by the company.

Look for a recurring moment

The interesting distinction is between having an idea and being able to communicate it. A useful starting exercise is to collect moments that begin with “I just need to…”: explain a screen, compare two options, or show the order of a process. Ask how the person handles that moment now, how frequently it occurs, and which step consumes their attention.

This gives a small product a more concrete brief than a list of possible features. An initial demonstration can follow one complete task. Show the starting material, the few actions required, and the usable result. Could that result be handed to another person without an explanation from the maker?

Give the first version a boundary

Our suggestion is to write one promise that can be tested in a short session. For example: a person without design training can communicate the relationship between several screens. Keep unrelated ideas in a separate list. A list preserves them without letting them consume the first release.

Support is part of the experiment. If a feature always needs its author standing nearby, it may not yet be usable. If a workflow works only on the maker's own computer, it has not demonstrated that a stranger can finish it. Watch several people attempt the same task. Their pauses and workarounds are more informative than a general expression of enthusiasm.

A practical exercise

Choose a familiar situation and write down the user, the trigger, the current workaround, and the desired outcome. Build a small deliverable around that sequence. Then watch for voluntary repeat use and whether the result travels to someone else.

A company's history cannot promise anyone else's income. What this story offers is a useful prompt to narrow a problem and take ordinary constraints seriously. Available time, family responsibilities, and the cost of supporting a tool belong inside the design brief. They are not details to postpone until after the exciting part.