A good proposal is like a book. It tells a story. It needs a clear beginning that sets the stage with the company background and introduction, followed by the problem statement and the client’s challenges. The climax comes with the investment that’s required, leading into the resolution where we outline our methodologies and case studies. Finally, it closes with a strong conclusion.

The hardest part, however, isn’t putting words on a page, but rather it’s deciding what story we are telling together.

Hi, I’m Adlin. I’m the Business and OPS Executive here at Stampede and this is my debut article. At Stampede, “Business and Ops” is really about making things work. I connect the dots between people, processes and projects. Some days that means handling timelines and documents, other days it’s about helping shape how we tell our story to clients. I’ve spent the past three years helping our team craft proposals for design and development projects.

What’s unique about our approach is that we don’t separate business development from delivery. When we respond to an RFP, the people writing the proposal are the same ones who will eventually build it. Designers, Developers and Ops come together to figure out what makes the most sense for the client. It’s a collaborative process that feels less like pitching and more like building, just on paper first.

What I’ve noticed is this: the stage that eats up the most time is not the writing itself, but the planning. Just like authors spend more time outlining, seeking inspirations, scheduling their time to write, we spend most of our effort aligning on ideas before we begin writing the proposal. And when you have several “authors” writing with different perspectives, it takes work to pull the story together. What separates a confusing and a clear proposal is how we communicate. Strong internal conversations between ops, design, and dev become the backbone of a strong solution proposal.

Internal alignment create external clarity

The first thing we do when a new RFP comes in is scan the scope of work. What’s needed? What’s the timeline? Who are the best resources we can send? We form assumptions here, but we don’t react yet. Instead, we gather every question we have, list them down, and send them to the client. It’s important to clarify these early because the cost of fixing a mistake later is far higher than the cost of validation.

Once the client replies, the real groundwork begins. My role in Ops is a bit like being the PM of a project. I’ve experimented with many PM tools for tracking proposal tasks, but for me, Notion is home base. It’s where we collect every piece of information so everyone has access to the same page.

This first step is crucial. If the team is misaligned internally, the proposal will read as vague, inconsistent, or overly technical. We don’t want that. A clear, aligned RFP tells the client we get you, we’re organised, and we can deliver.

The RFP is a reflection of a team dynamic

An RFP is often a client’s first impression of what it feels like to work with us. I don’t come from a design or dev background, so I look at our proposals differently, in the big-picture sense. Einstein once said,

If you can’t explain it to a six year old, you don’t understand it yourself.

Well, at Stampede, I am that six year old (Theoretically, of course. Don’t report me for child labour).

Because I don’t speak the same technical language, I make a good proof reader. If the flow makes sense to me, it’ll make sense to client’s procurement team. For me, that flow comes down to three simple questions:

1. What is the goal of this project?
2. Why us?
3. How can we help?

In fact, these are the first questions we ask each other during our kickoff call. Our internal conversations help surface the right differentiators, which case studies to showcase, what methodologies that are the right fit, the investment, and the timeline. When the story flows, clients don’t just see capability, they feel our confidence. A well-structured proposal signals discipline and care, which is why strong team dynamics matter.

Communication reduces last-minute stress

At Stampede, deadlines are everything. In projects, we set our own deadlines and take full accountability. But proposals work differently. The deadlines are strict, often dictated by the client’s internal portal. Sometimes even a minute past the cutoff means rejection.

That’s why we work backwards. If the submission is due on the 27th, we mark it as D-Day and then map out what needs to be completed on the 26th, 25th, and so on. From there, we assign specific tasks and resources. Designers handle design scope and methodologies, devs lead the dev scope, and ops take care of business documents while making sure everything matches the client’s requirements.

One trick we’ve adopted is setting an internal deadline before the actual one. That buffer gives us space to proofread and polish without panic. Early communication and clear delegation go a long way in avoiding last-minute stress.

When everything finally comes together, a good proposal becomes more than just a submission. It becomes a reflection of care. For the client, it brings clarity and a sense of confidence that they are in capable hands. For the procurement team, it makes their job easier by showing that we’ve understood not only the brief but the intent behind it.

Every proposal forces us to slow down and make sure we’re solving the right problem before we ever start building. It sharpens how we collaborate, how we communicate and how we grow as a team. So if you’ve ever received a proposal from Stampede, now you know where the quality and consideration came from. They came from a lot of conversations and probably a few very strong coffees.

A good proposal is like a book

As someone who loves a good storybook, I know the mixed feelings that come at the end of one. Relief, nostalgia, sometimes sadness and (mostly) joy especially when the questions you had at the beginning have been answered. You leave the book with more clarity than when you started.

Proposals work the same way. At the end of reading one, clients should walk away with confident answers, and the feeling that someone cared about their problem, not more questions. That’s the goal. And the best way to get there is through strong team communication.

Every proposal tells a story. This was ours and I’d love to hear yours!

Let’s connect on Linkedin?

The post Proposals and the conversations in the margins appeared first on Stampede: the strategic design & technology company.

What we had to learn

For example, our UX team has worked with a fashion-based company and it was a welcome climb for us. We were initially confused about their terminology and struggled a bit. However, the exposure helped us understand the client and made the rest of the workshop a smooth sail. To paint a better picture, here are some examples of what we had to learn:

• Principals: People who own the brands
• High Street: Young fashionable brands like Uniqlo and Zara

If you read these out of context, you’d probably link principal to your school’s principal, and high street to expensive brands. These are some of the terms that we learned during the workshop and had to get adjusted to.

How a typical Stampede UX workshop runs.

I don’t fancy myself as a fashionable guy, nor do I engage in finding out the latest trends, so an industry like fashion was a huge hurdle for me to leap over. What I learned from that workshop was that, depending on our interests and experience, certain industries can be easily understood while others can be alien. Learning your client’s language is not easy, but is necessary for UX.

What we had to do

If  you’re still with me, I thank you for reading thus far. At this point you’re probably interested in knowing what you need to do to better understand your client? There are a few points that I’d like to share with you from what the UX team learned as a whole.

Step 1: Be prepared

This goes without saying. In a workshop, your client expects you to lead it, and lead it well you must. As the UX facilitator, you’ll need to guide them along the agenda and be able to answer questions that are part of the UX process. While being able to answer these questions effectively on the fly is great, not all of us are gifted with this talent. Here are some tips on how to be prepared.

We bring a LOT of Post-it notes.

1. Learn the industry. This goes without saying. Start by doing research on your client, and then follow-up with their competitors. Identify what terms seem to be strange to you, but are used by the client and their competitors.
2. Have the agenda shown visibly in the room. You and your clients can refer to this to know where the workshop is presently at. Instead of this being part of your slides, have it visibly shown on a whiteboard or a signage that you can put up somewhere.
3. Make sure your materials are ready. At Stampede, we prefer to use large sheets of paper to draw our diagrams. So we always bring extra rolls of paper, markers and post-its.
4. Bring along some sweet delights. What I mean by this is to prepare a bowl of candy for both your team and the client. The sugar in these will perk the person up and also prevent them from dozing off.
5. Do a quick rehearsal of the workshop. This is especially important if you are new to running a UX workshop. Work with your team and run the workshop internally before you face the client. By doing so, you can also pick up on areas where you can improve or omit from the workshop.

Once your client sees that you are fully prepared, it puts away some of their uneasiness and allows them to open up and speak freely. This leads to their use of industry jargon.

Step 2: Listen first

The purpose of the workshop is to learn your client’s problems and to also figure out who their customers are. The workshop will go smoothly when both parties are engaged with one another, and this doesn’t happen when both sides are trying to speak. Be the listener and respond promptly. Some areas that you should focus your listening attention are:

• The problem. To fix a problem, you need to fully understand what is causing it in the first place.
• Goal of the business. By learning the client’s goal, it will be easier for you to understand their expectations.
• Who are their customers. This part is essential for creating user personas, and who better than the client to describe the customers.
• Pick up the jargon. If a word seems to be used in a way that is not common to you, chances are it is being used differently by the client. Make a physical or mental note on this.

Step 3: Speak out

What better way to understand the client’s tongue, than to speak their lingo. The second step is a crucial pre-requisite to this step, as it takes whatever you have passively learned by listening, to actively learn the language. Now some of us don’t like making mistakes, but being able to owe up to it shows that you are willing to learn. This in turn leads to the client being aware of your situation that you aren’t familiar with their world.

Client participation goes hand-in-hand with communication.

Start by using the industry terms when talking to the client, chances are you might nail it’s usage or get it wrong completely. Don’t worry, nothing bad will come out of it. Instead the client will likely correct you and give you a clearer definition of the term. While you are speaking, make sure you don’t neglect the listening part as it never really ends until the workshop is over.

Practice, practice, practice

Like learning an actual language, practice and experience will improve this skill over the number of sessions. Once you get the hang of it, you can start to dive into more varied industries that widens the types of projects that you and your company can take on.

Have you come across a client, where you had trouble understanding due to their use of jargon? Do share your experiences with us. We’d love to know more about it and in turn, learn from it.

The post Tales from the UX Workshop: Learning to Speak your Client’s Tongue appeared first on Stampede: the strategic design & technology company.