Business Growth Brief · By Leanne Reichhoff
“We need a new website” describes a project the company is considering. It leaves an important question unanswered: what brought the company to that decision?
The site might be difficult to update. It might show outdated services. Customers might struggle to find information, or the business might have developed expertise the current pages barely mention.
Each situation deserves attention. Each can lead to a different recommendation.
At Re3, we want to understand the issue behind the request before deciding what work makes sense. That applies to websites, branding, marketing, service development, and operational systems.
Describe the Issue Before Choosing the Scope
Once a project has a name, the conversation can move quickly into execution. Who will build it? What will it cost? How long will it take?
Those questions matter, but the answers depend on what the work needs to accomplish.
A company concerned about poor-quality inquiries needs to examine what attracts those inquiries and how it communicates fit. A company whose staff cannot update important pages needs to understand its technical and internal publishing requirements. Both may request a website, but they need different things from the engagement.
Start by describing what is happening in the business. Identify who is affected, where the issue appears, and what people are having difficulty doing or understanding. The description should be concrete enough that another person can examine it with you.
Separate What You Know From What You Suspect
“People are confused by our services” could reflect several kinds of evidence. Perhaps prospects ask the same question repeatedly. Perhaps sales conversations require a lengthy explanation. Perhaps the team suspects confusion because inquiries have slowed.
These observations do not carry the same information. Repeated questions can identify a specific misunderstanding. Fewer inquiries tell you something has changed, but may not explain why.
Record the evidence and the assumptions separately. Useful inputs may include customer questions, sales notes, website behavior, inquiry quality, internal workarounds, and feedback from the people delivering the service.
You do not need perfect information to begin. You need enough honesty about what is known to avoid treating an assumption as a settled diagnosis.
Define the Improvement You Want to See
“Launch the new site” describes completion. It does not fully describe the improvement the business hopes to achieve.
Depending on the issue, the intended improvement might be that prospective customers understand the core services before calling, staff can maintain important information, or the company receives more inquiries suited to its expertise.
Some improvements can be measured directly. Others require observation and feedback. Either way, define what you expect to change and what evidence would help you assess it.
That creates a useful basis for discussing scope. If a proposed feature has little connection to the intended improvement, ask whether it deserves the time and investment. If an essential piece is missing, address it before production begins.
Consider What Else Affects the Result
The deliverable operates within a business. Its usefulness depends partly on the decisions and processes around it.
For example, a company may have added several services without deciding how they fit together. A website team can arrange the pages, but it still needs a clear answer about what the company wants to emphasize and how customers should understand the offer.
Similarly, more marketing may generate interest while an inconsistent inquiry process leaves prospects waiting. A new system may offer helpful capabilities while unclear responsibilities prevent anyone from maintaining it.
Look for decisions that need to happen first and responsibilities that need an owner. This can confirm the project as proposed, narrow its scope, or reveal related work that should be included.
Use Four Questions to Examine the Request
Before starting, ask:
- What is happening now? Describe the issue in terms of customer, employee, or leadership experience.
- What evidence do we have? Identify direct observations and separate them from explanations you have not yet tested.
- What would we like to be different? Describe the improvement the work should support.
- What else could affect the result? Consider services, sales, team capacity, systems, and connected efforts.
You do not need to arrive at Re3 with everything diagnosed. Helping examine the situation and recommend an appropriate approach is part of our responsibility.
Try writing a paragraph about why your next project is needed without naming the deliverable. Then compare that paragraph with the work you are planning. Would completing the project exactly as requested address the issue that prompted it?
