How to Pave a Path Forward

Photo by Will Ellis

Paving a path forward is a skill.  The more you do it, the better you get.  If there’s one place where your ability to pave a path forward gets tested, it’s driving projects.  On sizable projects, the gap between your project vision and current reality can be overwhelming.  Somehow you have to get from point A to point B and there’s not always a map.  Sometimes you’re the map maker.  This is especially true when your heading into uncharted territory.  Even when you have a map, it doesn’t mean it’s going to be easy.  What you need is a way to pave a path forward.  This post is about some of the lessons and the tools I use to pave paths forward.  It’s from the school of hard knocks over many projects large and small.  Enjoy …

How To Be Closer to Done
You know you’re closer to done when you can show ….

  • 3 competing models.  Be able to argue the key points and have alternative solutions.  At the end of the day, there’s no egos — it’s about measuring against effectiveness, knowing the priorities and making the right trade-offs
  • The incremental path to implementation.  You know where you are, where you could be (one of the solutions), and the incremental step to get there.  For example, what could you do now? how? why?  what’s a way to chunk the solution?
  • Work breakdown structure (WBS).  You know the work to be done.
  • Blocking issues.  You have a list of the blocking issues.
  • High risks.  You know your high risks.

That’s the short list.  When you have those in hand, you’re at least you have a way forward.  The work breakdown structure tells you a lot about the nature of the work.  if you know where you’re blocked, you know where you need help, as well as the kind of help you need.  Knowing your high risks will help keep you from falling off the cliffs.  By knocking out some of the high-risks earlier vs. later, you create a glide path.  When you have 3 competing models, you have a good sense of some of the trade-offs and at least you have potential solutions to test.   Being able to chunk up a solution into smaller, testable paths, is the key to incremental progress.  It helps you learn and adapt as you go, based on feedback.

Test Implementation and Find the Surprises
Testing implementations will help reveal the surprises.  It’s where the rubber meets the road.  If you aren’t finding surprises, you probably aren’t testing enough implementation.  If you don’t know the work to be done, you don’t  know the right people.  The right people can help you identify the work to be done.  If you aren’t testing implementation, you don’t know what you don’t know.
Don’t Do Big Design Up Front
Avoid Big Design Up Front.  Paving a path forward is about taking action.  It’s a bias for action over analysis.  This is how you combat analysis paralysis.  Your actions inform your analysis.  Here’s the keys:

  • Don’t over-engineer up front.  What you don’t want to do is over-engineer and Big Up Front Design a solution that will need to change and be adaptable anyway.
  • Know how to flex your solution.  You want to know how to flex the implementation so as we learn more, we improve it and so we can rapidly test and make changes.
  • Stay focused on outcomes and chunking results.  Think about how to bite off what you can chew.  Find your best pace so you can stay focused on outcomes and chunking results.
  • Outcomes guide your priorities.  Use your outcomes as a roadmap and prioritization framework.
  • Know your timeboxes.  Balance what you can do based on the work to be done, what you can do with the hours you throw at the work, and your capabilities.  It’s better to have a sustainable pace, than burnout to early or run out of steam.  Time is a great way to set boundaries and keep your energy strong.   See Timeboxing for Getting Results.

Remember this doesn’t mean don’t do any design up front.  Instead, it means do just enough to get started and keep a bias on action and testing your thinking.  Feedback is your friend.  Be able to respond to change.

Distinguish What’s Ideal, What’s Possible, and What’s Practical
Success is a slider bar.  You need to keep a range of solutions under your belt.  Solutions are a moving target.  Time and situations change things.  Here’s the keys:

  • Distinguish between the right thing to do and what you can do.  Distinguish between what’s the right thing to do and what you can do that’s practical for your situation.  See First Know What’s Right for Effective Decision Making.
  • Know the gap between idea and reality.  There’s always a big gap between the *idea* and *reality.*   It’s going to force important trade-offs.
  • Right up front you should know to solve it in a way that’s highly adaptable and super-easy to change …
    … and assume that no matter what, there is no model that makes everybody happy
  • Know the slider bar of success.    Test your solutions against scenarios.  Measure effectiveness.   By testing against scenarios and measuring effectiveness, you can decide how to tune and prune to reduce complexity or improve efficiency, .. etc.

Do it, review it, improve it.
Prototype and do dry runs.  Another way to think of it is incrementally rendering a solution.    The mistake is to analyze a castle in your mind with no reality checks.  Bounce your solution against the reality wall to see what sticks.  Use the feedback to improve.  See Expectation Shapes Reality.
When’s It Done
Something is almost *done* when you can use it to solve the problems you set out to accomplish.    Covey defines success as when the response meets the challenge.  Another way to gauge your level of doneness is to measure against your objectives.  Objectives are a great forcing function.  They force you to clarify what you want to accomplish.  You can also write “tests for success.”  Tests for success are simply one liner statements about what good will look like.  At the end of the day, it’s various stages of *done enough* and *good enough* for now.  To avoid perfectionism, remember to version your perfection over time.
What Don’t You Know
Periodically, ask yourself what don’t you know?  Test yourself.  Paving a path forward is about dealing with ambiguity and making incremental progress.  It’s also about dealing with the awkward stages of learning and growth.  Here’s the keys:

  • How to stage the work or test implementation
  • How to test changes
  • How to avoid big design up front.

Build on what you know.
Figure out what you know, don’t know, need to know next.  This is how you continuously move forward.  Sometimes, the best way to move forward and build confidence is to recap what you know.  What you know is your foundation.  Continuously build on your foundation.
Tests for Success
Know your tests for success.  This will help you avoid churn and guide you when you feel lost.  Here’s the keys: 

  • Know what you’ll most likely get wrong.  What will you get wrong?  Try to figure out what you’ll potentially get wrong so you know your risks and where you might need to spend more energy.
  • Know what good looks like.  How will you know what good looks like?
  • Know the tests that will flex your solutions.  Have you figured out the tests that will fail you?
  • Know your scenarios.  What scenarios did you test against? 

I often find myself turning back to my tests for success to confirm whether I’m on track.  When you’re in the thick of things, it’s the tests for success that help guide you forward.

Test Effectively
Here’s some things to keep in mind when testing your solutions:

  • How did you test?   How you tested can be as important as what you test.  Know what you’re checking for.
  • Which customers did you test with?  Are they representative of the results you’re going for?
  • Be able to show and tell.  This is how you can get effective feedback.  If you have a competing model, (have at least 3), then have a way to show the models quickly and be able to get the right feedback on them.
  • Test the model against various scenarios.  The more you flex your solutions, the more you’ll find the surprises.
  • Be able to defend your key decisions.  This is how you test your own thinking.  Be able to quickly expose the trade-offs around decisions.  Ultimately, the most robust solution will survive (and the weak solutions will be exposed through precise questioning.
  • Leverage multiple perspectives.  Assume people you know have different perspective and levels of experience.  Find ways to use their best thinking.

Expect to Churn and Learn — Don’t Expect to Avoid Rework
One of the worst ways to churn is trying too hard to avoid rework.  It’s easy to fall into the trap of trying to do everything right up front.  Instead, make mistakes.  Fail fast.  Fail forward.  Make your mistakes, learn from them and move on.  Here’s the keys:

  • Don’t avoid rework — embrace change and be able to change quickly.
  • No matter what the solution, it will have to be evolvable.  Life’s not static.
  • No matter what, it will have to change and flex over time
  • No matter what, you’ll need to change it based on feedback and actual usage.

Who’s Your Customers — Where’s the Pain?
Get a perspective on your downstream pain points.  The most important things to know are:

  • Who’s the customer?
  • What problem are you solving?
  • What are the usage scenarios?
  • You need to know who your customers are and what problem you’re solving.  This is about relevancy.

What Business Cases Will You Impact
Always know the business case.  Even if it’s charity work, it’s good to know that you’re making the maximum impact for your effort.  It’s good to know your priorities.  Time and energy are limited resources.  The business case will help you focus.  Here’s the keys:

  • Did you figure out some of the higher-level issues — like the business cases? …
  • What’s the cost in terms of time and effort?
  • Can you show improvement? Can you reduce friction around the problem?
  • Can you chunk it up?
  • What’s the expected usage?
  • What’s the expected impact?

My Related Posts


  1. JD,
    This one is very comprehensive and practical too – i can use it as a whole or pick the one i specifically interested, for example, at this point i loved these since it is very relevant to my current situation:
    – Distinguish What’s Ideal, What’s Possible, and What’s Practical
    – Don’t Do Big Design Up Front
    Very good stuff!

  2. Hi JD

    This is an fantastic post. I love the step by step on this one. I have always love your work, but this one is awesome. I am going to stumble this one.
    Thank you,
    Giovanna Garcia
    Imperfect Action is better than no Action

  3. @ Alik

    Thank you. I find myself turning to these practices on a regular basis. They’re simple, but effective. I ask myself what do I know, don’t know, need to know next fairly regularly to build a foundation and keep from getting stuck.

    @ Giovanna

    Thank you! I think this post is very consistent with your point on imperfect action. I particularly like your mantra – imperfect action is better than no action – and I think it helps pave a path forward.

  4. These 2 points are so key:
    “Paving a path forward is about taking action. It’s a bias for action over analysis. This is how you combat analysis paralysis.”


    “Fail fast. Fail forward. Make your mistakes, learn from them and move on.”

    Those are actually 2 of the biggest lessons I’ve learned in the past few years in my journey to entrepreneurship.

    Nice post, thorough and detailed as usual. Good stuff!

  5. Very detailed post. I love that you look at so many angles.

    I have to admit that I avoid rework. Everyone knows “the devil is in the details” because that’s where the hard work really is.

    The bloggers that I enjoy reading the most are the ones that really flush out what they are trying to say before they publish. I’m still working on enjoying the job of triple checking my blog posts. Not quite there yet, but I’m getting stronger every day.

  6. @ Christine

    Thank you. I like the way you highlighted those two points — I think those are the key lessons.

    @ Karl

    Thank you. I think it’s the team and project variety that’s helped me gain perspective. It’s one thing for me to get results, it’s another to help unleash the team.

    I used to avoid rework too. What changed for me was that I realized I could produce a better result by versioning over time. When I tried to get it right up front, I always missed something. Sometimes what I missed was important time windows that I couldn’t get back. I also learned that putting something out there helps me test it against reality and then use that feedback for a better result. It’s where the rubber meets the road.

    I think of posts in versions too. I like the idea of putting a “good enough” post out and then say it a better way later based on feedback and what sticks. At the same time, I try to keep a decent bar so it’s more help than harm. It’s a slider bar 😉

Comments are closed.