Listen to the full episode now:
Websites get stuck when decision-making processes aren’t clear and when there’s no allocated decision-maker to keep moving things forward.
We sat down with Beth Navarro, Workhorse’s Associate Director of Web Services, to talk about why website projects get stuck in approval cycles and what the smoother projects do differently.
Key Takeaways
- Set 2-3 goals before kickoff. Give the project a lighthouse, and use it to settle disputes instead of escalating them.
- Launch, then improve. Waiting for perfection before going live trades momentum for information you’ll only get once real users show up.
- Keep the approval group small. One to three people covering technical, marketing/sales, and operations beats a dozen partial stakeholders, and someone needs real authority to make the final call.
- Make feedback specific. Vague comments burn revision rounds guessing at what “not a fan” actually means, so tie feedback to the goal and give the team something to act on.
Perhaps you’ve been here before: Your website project that was supposed to take twelve weeks. It’s now week twenty.
The design has been “almost approved” for a month. Or maybe, three people have opinions about the hero image. Or worse still, someone from another department just joined the review and wants to revisit a decision everyone else made six weeks ago.
At this point, the problem isn’t really with the website, but with the way decisions are getting made.
Associate Director of Web Services, Beth Navarro, was on the Workhorse Podcast this month to talk about this very challenge.
Beth leads our project management team, so she’s seen plenty of timelines go sideways. And in her experience, many of those problems start long before anyone opens Figma.
The Real Reason Websites Stall Before They Start
Website delays begin before design: they start with a goal the team never fully agreed on.
This is easy to miss because a website touches so many parts of a business. Marketing wants stronger conversion numbers, but sales cares about lead quality. HR has recruiting needs, but customer service wants people to find answers without calling. Internal teams have their own set of technical requirements.
All of those needs are legitimate. But without a shared priority, they start competing with each other.
Beth describes the solution as one clear project goal – a lighthouse, as she calls it. Maybe the priority is increasing conversions on a specific form. Maybe it’s making the site easier for an internal team to manage. Whatever the goal is, everyone needs to know what they’re steering toward.
Then, when someone proposes a change halfway through the project, you have a useful way to evaluate it: Does this help us accomplish what we agreed to accomplish? Does it help us get to our lighthouse?
Sometimes the answer is no. Sometimes the answer is that the goal itself has changed. That’s worth discussing too. But if the goal changes, the scope and timeline usually need to change with it.
What causes the most trouble is letting the project drift in a new direction without acknowledging that anything changed – that’s the project moving away from the lighthouse, which is frustrating for everyone involved.
Why “Perfect Before Launch” Is the Wrong Goal
Another common source of delay is the tendency to treat a launch like the moment a website becomes permanent.
Teams start thinking every page needs to be finished, every edge case solved and every detail perfected before the site goes live.
But websites don’t work that way.
Once the site is live, you start getting information you didn’t have during design. You see how real visitors move through pages: what they click and where they get stuck. Then, you improve the site based on what they’re actually doing.
Waiting for perfection before launch often means making more decisions with less information, which also puts the project’s momentum at risk.
A project that keeps moving has context. People remember why decisions were made, which keeps stakeholders engaged, which means feedback comes back quickly. Once stretches of days or weeks start passing between decisions, people forget earlier conversations, priorities shift and old questions start resurfacing.
Getting that momentum back takes time. Protecting it deserves almost as much attention as protecting the budget.
What Happens Between Strategy and Design
As Beth notes, the strategy phase of a website project often feels relatively easy.
You’re talking about site maps, page structure and user journeys. Everyone is looking at boxes, words and concepts. It’s still possible for five people to look at the same wireframe and picture five slightly different finished websites.
Then the first design arrives.
Suddenly, all those abstract decisions have a visual form, and sometimes a client sees the homepage and realizes it looks nothing like the website they’d been picturing.
The problem is sometimes the design, but more often than not it’s the expectation: Sometimes the team had a strong visual preference that never made it into the strategy conversation.
All of that strategy work before design matters so much.
If you already have a picture in your head, share it. If there are styles you hate, say that too. Strategy gives the team a chance to uncover those preferences while they’re still relatively inexpensive to address.
Otherwise, the conversation happens during design, when changing direction takes considerably more work.
The “Show Me What I Don’t Want” Problem
Of course, sometimes you don’t know what you want until you see something you don’t.
That’s normal.
Design is hard to discuss in the abstract, especially if you don’t spend your days thinking about typography, spacing, image treatments or button styles. You might struggle to explain your preference beforehand, then recognize immediately that something feels wrong when you see it.
That’s also why a revision that ends with, “Actually, let’s go back to the first version,” isn’t necessarily wasted time. You learned something. Seeing the alternatives helped you make the decision.
The same logic applies to the homework your web team gives you.
If they ask for examples of websites you like and dislike, don’t rush through it. Try and find examples. And don’t stop at sending links. Explain what you’re responding to.
Maybe you like how one site uses photography but hate its navigation. Maybe another feels too corporate. Maybe you keep gravitating toward sites with lots of white space and don’t know why.
You don’t need design vocabulary. Your reactions give the design team something concrete to work from.
An hour spent gathering those examples early can save a lot more time once design is underway.
How Many Stakeholders Should Review Your Website? (Fewer Than You Think)
Website projects slow down because they have a way of accumulating reviewers.
Someone thinks HR should weigh in. Then sales needs a look. Then IT. Then a senior leader wants to see the homepage before approving anything. Soon, a dozen people are commenting on the same design from completely different perspectives.
It might feel thorough, but it usually makes decision-making harder.
You don’t need someone from every department in every review. Beth recommends keeping the core group to roughly one to three people who can represent the areas the website genuinely needs to serve.
For many projects, that means covering three perspectives:
- Technical
Forms, integrations, servers and IT requirements - Marketing and sales
Messaging, user flow and conversion - Operations
Internal processes and the way your team will use the site day to day
Other people can still provide input when their expertise is needed. They don’t all need to become permanent members of the approval committee.
In fact, says Beth, someone needs the authority to make the final call.
And crucially, choosing a point of contact only works if that person has enough authority to resolve disagreements.
Otherwise, you’ve given someone responsibility for moving the project forward without giving them the ability to make the decisions required to do it.
How to Give Website Feedback Without Blowing Your Timeline
“Not a fan of this hero image.”
It’s a perfectly understandable reaction. It’s also difficult feedback to act on.
What’s wrong with the image? The subject? The composition? The colors? Does it feel too staged? Is the problem the image itself, or the way it interacts with the headline?
Without that context, the design team has to start guessing.
That matters because website projects usually include a defined number of revision rounds. At Workhorse, that’s often two rounds per page.
If the first round gets spent interpreting vague comments or sorting through contradictory feedback from different stakeholders, you haven’t gotten much closer to the final page. Now the meaningful refinement work starts in round two, and what should have taken two rounds starts creeping into a third or fourth.
Before sending feedback, ask whether someone unfamiliar with the conversation would know what to do with it.
“Change the image” isn’t enough.
“This image feels too corporate for the audience we’re trying to reach. We’d prefer something candid that shows the product being used in the field” gives the team somewhere to go. And if you have an example you do like, even better.
The more specific the feedback, the easier it is to turn into a revision.
How to Run an Un-Stuck Website Project
Website projects that move smoothly tend to get a few things right early.
They agree on what the site needs to accomplish. They keep the approval group small. They give someone the authority to make decisions. And when they give feedback, they make it specific enough for the team to act on.
None of this is particularly glamorous. Most of it happens before the finished site starts taking shape.
But doing that work early keeps the project moving when the harder decisions arrive.
Then strategy can move into design, design can move into beta, and your website can get in front of the people it was built for.
Let’s build something great, starting with a clear approval process.