There is a tendency to write a problem statement as the problem you want to solve (i.e. the solution). For example ‘we give users no guidance on X’ is unlikely to be the problem statement rather than ‘users are confused’, the former is a solution disguising as a problem and the latter is actually the problem which may have many other solutions.
Links to this note
Writing is the much-discussed secret to building great remote teams. How do you write for a remote team?
Describe the Solution in Terms the Buyer Uses to Evaluate It
When you sell solutions not software, you need to be as concrete as possible about the buyer’s use case so you can describe your solutions in the same terms they use to evaluate it. For example, if their burning problem is too much manual work—dig into what the manual work is and how they decided this was a big problem, then describe the solution in terms that match (e.g. how many reports, hours, mistakes, etc. does the solution save).
A Single Cistercian Numerals Indicates a Value from 1 to 9999
Unlike Arabic or Roman numerals, a Cistercian numeral can represent any number between 1 and 9999 with a single glyph. This makes for a compact representation which were used for recording dates, indexes, numbering, and even used for labels on an Astrolabe.
Don’t Ask What the Problem Is, Ask What the Situation Is
It’s common in product and engineering circles to constantly ask people “what problem are you solving?” While this can be useful for focusing work on the right things, it also leads to solutions disguised as problem statements and self-referential arguments. Instead, ask “what’s the situation?”. This gives space between facts and the interpretation of those facts which makes it easier to understand and spot errors.