Problem statements: start with the "why", not the "how"

For the last couple of years, I spend two weeks each year teaching AI fundamentals, patterns and solutions to aspiring cloud architects from this one FAANG (or MAANG, MAMAA, what have you). The syllabus is already set, but I make it a point to add value in each cohort by imparting relevant, but game changing advice, particularly relating to their upcoming certifications and examinations.

TLDR; this year, the cohort is a little more engineering-savvy. Most engineers tend to overthink problems and over-engineer solutions, in addition to being susceptible to shiny object syndrome. This is relevant to most of us who build on shiny new tech. We are often distracted and tempted to dive into solution building before we the problem is understood. We end up in a spiral refactoring or building the next feature, not quiet knowing when to stop. The game-changing advice I had for them was ask (before diving into architectures, and prescribing solutions): "what is the problem statement that best captures this question or issue?".

The problem in broad terms: what is it that you can't do or can't do well enough? What needs to change or improve?
Scope or criteria: what aspects of the organisation or problem needs solving, and what is the criteria for done?
Break it down into sub-problems if needed: articulate the problem statement, scope and criteria for each one.
Avoid producing any architectural diagrams, or committing to solutions and components before the problem statement is clear and unambiguous.
If unclear or ambiguous, keep questioning until clarity emerges.

Now, this two-week intensive program is intended to prepare these cloud architect aspirants with most of the basic knowledge about data engineering, as well as cloud and AI solutions. It is highly modular, but the the syllabus don't encourage application or synthesis of knowledge across domains.

My solution to this was a hypothetical case study drawn from real-world use-cases: an early stage startup has had some traction with their B2C SaaS. They now have 20K monthly active users globally, but have been receiving complaints and feedback from users in EU of a lack of GDPR compliance. Their web-based app is currently hosted on a different cloud provider and running a particular stack. It needs to be GDPR compliant.

Over the next two weeks, we're going to build on this case study, working up to a full hypothetical solution architecture. I tend to adopt socratic methods when working with adult learners, and this is how I've nudged them into the Architect's mindset on day 1:

Most of them were tempted to dive into specifics, application and database migrations to cloud. So we refined the problem statement: disruptions and downtimes have be kept at a minimum (preferably none).
They realised only EU users needed GDPR compliance, but they also needed to figure out if there was a way to identify EU users in the current application stack. They also learnt they don't know anything about the current architecture and stack. They now know to ask questions about the existing environments.
Each discovery opened a new can of worms that refined the problem statement, added new subproblems and got them asking more questions.

It's a pattern that works when answering their certification exam questions, and it applies to any sort of solution building (even vibe coded ones). How this applies to our your AI builds:

Define the problem, the scope and criteria: know what you're solving for, and aim to solve exactly that, and nothing more.
Do not make decisions on stacks, databases, libraries or write a single line of code until the problem is clear and unambiguous.
When articulating your stack, pick the solutions (databases, libraries etc) best addresses each technological challenge while keeping the smallest footprint possible. For example: SQLIte suits most use cases, you don't really need a fancy firebase or firestore implementation until you're horizontally scaling your app.
Prioritise bug fixes and features that directly tackles the problem. Everything else can wait until the next phase.

It's easy to miss the forest for the trees. The above is how you remind yourself and remain grounded in the problem you're solving and not just the excitement from building with AI.

8 comments