Part 3: Understanding Your Goals Before Designing And Implementing Software

In the previous articles, we explored stakeholder interviews and the architect’s toolbox. Now, let’s focus on one of the most critical aspects of software architecture: understanding what you’re trying to achieve before designing solutions.

The importance of clear goals

Too often, teams jump straight into technical discussions without fully understanding the organizational objectives. This leads to:

• Solutions looking for problems
• Misaligned technical investments
• Wasted effort on features that don’t deliver value
• Architecture that doesn’t support business growth

Worst-case scenario: Goals? What?

Sometimes you’ll find yourself in an organization where goals are:

• Unclear or vaguely defined
• Conflicting between departments
• Not communicated effectively
• Changing frequently without clear reasoning

In these situations, you need to help the organization define its objectives. Consider using frameworks like:

• North Star Metrics - A single metric that captures the core value you deliver to customers
• OKRs (Objectives and Key Results) - Clear objectives with measurable outcomes
• Business Model Canvas - Understanding how the organization creates and delivers value

Remember: without clear goals, any technical solution is just a guess at what might be valuable.

Challenging scenario: Goals are clear, but Product Vision isn’t

In this case, your organization has set clear and measurable objectives, but there is no clear path to how to make that possible from a product perspective:

• What is the conceptual solution, your offering, that will help achieve those goals?
• What are your users, customers, or actors in general that will interact with what you offer to produce the value that you defined in your goals?
• What are those interactions? What do they need, and what do they cause?

You need to follow a similar approach as for the first case. You can ask your stakeholders, e.g., Product Teams or Product Designers, to explicitly describe the Product Vision and map it to the organization’s goals. Ideally, the result should be a document, presentation, or visual—something you can use later as input to design the architecture.

Again, there are many frameworks for determining the product vision, such as User-Centered Design, Story Mapping, and Value Proposition Design. You can participate in the process if needed, but someone else should drive the exercise to build a Product Vision consistent with the organization’s goals.

Introducing the Tool Cards: Exploring Our Goals

Let’s look at the first Tool Card from the Software Architecture Toolbox.

“Exploring Our Goals” summarizes how to reach one of the most critical inputs needed to build proper software architecture: the Organization’s goals. You may not need this card if you have clearly defined objectives.

Tool Card: Exploring Our Goals

Purpose: Understand and document organizational objectives

Format: Workshop or series of interviews

Frameworks to Consider:

• OKRs (Objectives and Key Results)
• North Star Framework
• Balanced Scorecard
• SMART Goals

Prerequisites:

• Access to leadership team
• Understanding of market context
• Historical performance data

Outputs:

• Documented organizational goals
• Success metrics
• Priority areas
• Time horizons

I’ll use the same format for all the tools in the Architect’s Toolbox: a card with fields to describe the tool, preferred format, frameworks, and preparation needed. Each card shows prerequisites and outputs.

Next to each card, you should link the topics from interviews that will be clarified by using this tool:

Tool Card: Defining the Product Vision

With organizational goals established, you can define the Product Vision. This card includes links to templates and resources for frameworks you might want to use.

Tool Card: Defining the Product Vision

Purpose: Translate organizational goals into product strategy

Format: Collaborative workshops with product and business stakeholders

Frameworks to Consider:

• Product Vision Board
• Lean Canvas
• Value Proposition Canvas
• Story Mapping

Prerequisites:

• Clear organizational goals
• Market research
• User feedback
• Competitive analysis

Outputs:

• Product vision statement
• Key features and capabilities
• User personas
• Success criteria

Please don’t forget to map how the output will help your organization:

Mapping tools to challenges

For each tool, map how the output will help your organization address specific challenges:

1. Unclear priorities → Organizational goals provide focus
2. Feature creep → Product vision sets boundaries
3. Technical debt decisions → Goals help prioritize what to fix
4. Architecture trade-offs → Vision guides decision-making

The flow from goals to architecture

The relationship is straightforward but often overlooked:

1. Organization Goals define what the business wants to achieve
2. Product Vision translates goals into user value
3. Technical Architecture enables the product vision

Each level constrains and informs the next. Without clear goals, your product vision is guesswork. Without product vision, your architecture is just technology for its own sake.

Common pitfalls to avoid

Starting with technology

“Let’s use microservices!” before understanding if you need them

Assuming goals are static

Goals evolve; your architecture should be flexible enough to adapt

Confusing activity with progress

Building features doesn’t equal delivering value

Working in isolation

Architecture decisions need business context

Next steps

Oh boy! Your first days navigating software architecture are far from technical (I told you!). So far, you’ve been using tools to interview people and collect documents you can use as input. Or, even more fun and engaging, you’ve had the opportunity to connect with other people and create some documentation (goals, vision) collaboratively to get what you need to move forward.

We’re getting there. One step at a time. These are essential preparations.

In the following article, we’ll cover your task entirely: documenting the current state of the system and its challenges. This critical input will help set the foundations for future decisions. Since the Software Architecture side owns that part, I’ll discuss the frameworks you can use in more detail there.

Key takeaways

• Goals first, solutions second - Understand what you’re trying to achieve before how
• Product vision bridges business and technology - It translates goals into actionable direction
• Use frameworks as guides, not gospel - Adapt them to your context
• Collaboration is essential - These exercises work best with diverse perspectives
• Documentation creates alignment - Write it down to ensure shared understanding

Remember: Great architecture starts with clear goals. Without them, you’re just building castles in the air.