Solution Map

01 / What a Solution Map Is

A customer’s challenges, mapped to a solution.

A Solution Map is the document a Sales Engineer shares with a customer to show how Sophos fits their situation. It takes the form of a PowerPoint deck, and it follows one line of reasoning from the customer’s problem to the proposed answer.

It starts with the customer: a business profile, the challenges they face, and the objectives behind them. Each objective comes with its requirements and the metrics that would show it has been met.

Then it answers. A requirements mapping sets each requirement beside the solution that addresses it and the value that solution brings. Another slide shows which products and services are in scope, and which are not.

The rest is practical: a solution architecture, the details of the scope, a transition timeline, and a clear split between what Sophos does and what the customer does. An appendix describes a proof of value, with success criteria that settle in advance what “it worked” means.

The structure is consistent, but every Solution Map is about one customer. The thinking that connects a challenge to a recommendation is the part worth getting right, and it’s the part the application supports: a Sales Engineer enters a customer’s details, challenges and objectives, the application matches them against a curated catalog of Sophos challenges and solutions, and the result is exported as the deck.

02 / The Beginning

A list of functions isn’t a product.

The initial request sounded straightforward.

Gather information about a company. Understand its business challenges. Recommend Sophos products based on those needs. Generate a PowerPoint presentation.

The stakeholders understood what they wanted the software to do.

What they hadn’t established was how someone should use it.

There was no complete user journey or finished interface specification connecting those capabilities.

Where should users begin? What information should the application gather automatically? What should remain editable? How should business context and challenges influence product recommendations?

These weren’t merely decisions about where to put buttons.

They determined how the application would work.

My responsibility was to answer those questions through the design and frontend implementation.

03 / Giving the Idea a Structure

Making separate functions work together.

I designed the workflow around a progression from understanding the customer to preparing a solution.

It began with company information.

Users could rely on AI to prefill details from sources such as Wikipedia or a company’s official About page. They could also provide the information manually.

Both approaches needed to lead into the same experience.

From there, users would establish the company’s business context, select relevant challenges, review product recommendations, and generate the final presentation.

Each stage depended on information collected earlier.

The challenge was to make those relationships clear without burdening users with unnecessary complexity.

The stakeholders had supplied the destination. I had to work out the route.

04 / Connecting Challenges to Recommendations

The products remain the same. Their relevance doesn’t.

Solution Map uses a company’s business context and selected challenges together to inform product recommendations.

The complete Sophos product catalogue remains available. The application doesn’t exclude products simply because they aren’t the strongest matches.

Instead, the recommendations differ according to the customer’s circumstances.

The matching logic was primarily handled by the backend, which I accessed through an API.

My responsibility was to design and implement the frontend experience around it: gathering information, organizing user selections, sending the relevant data to the backend, and presenting the results.

Those results then contribute to the PowerPoint solution map.

The interface needed to connect what users entered with the recommendations they received, without requiring them to understand the implementation behind the matching process.

05 / Building Under Constraints

Simple didn’t have to mean careless.

The stakeholders wanted Solution Map delivered quickly.

We had approximately one month to design, develop, and deploy the first version.

That left little room for extensive visual experimentation.

I concentrated on a clean, straightforward interface and a workflow that made the required functions understandable.

It wasn’t an elaborate design, but it didn’t need to be.

A complicated interface wouldn’t have made the product more useful, particularly when the larger challenge was connecting loosely defined functions into a coherent experience.

I handled the entire UI/UX and frontend domain, while my manager developed the backend.

That clear division of responsibility helped us move quickly. We could concentrate on our respective work while bringing the application together.

06 / Engineering Decisions

Working with what we knew.

Solution Map used Next.js, Redux, React Hook Form, and Zod.

At the time, Next.js was our established frontend framework. We hadn’t yet begun exploring the alternative stack I would later adopt for Sophos Builder.

Given the deadline, we continued with technologies we already knew.

Redux handled application state, while React Hook Form and Zod supported form management and validation.

The frontend communicated with the backend through APIs, including the services supporting customer information gathering and product recommendations.

Looking back, a lighter frontend architecture might have been sufficient.

But decisions have to be understood in the circumstances in which they’re made.

We needed to deliver an application quickly. Using a familiar stack allowed us to concentrate on the experience and functionality rather than introduce additional technology choices.

It was a reasonable trade-off for the project and its timeline.

07 / The Outcome

From a loose concept to a working application.

We delivered Solution Map’s first version in approximately one month, making it one of our team’s fastest deployments.

The application received considerable praise from users and stakeholders, particularly for the speed of delivery.

What I find most significant about the project, however, isn’t simply that we finished quickly.

We began with a collection of functional expectations and no complete picture of how the application should work.

Within a month, those requirements had become a working product with a defined user flow, AI-assisted customer research, business-context and challenge selections, tailored product recommendations, and PowerPoint generation.

The project also gave me a useful point of comparison for later work.

When I approached Sophos Builder, I was more willing to reconsider our established architecture rather than use it automatically.

That doesn’t mean the decisions we made for Solution Map were wrong. They suited what we knew and what the project demanded at the time.

The more lasting lesson was about design.

Knowing what software should accomplish is only the beginning. Somebody still has to work out how people will use it.