Save THOUSANDS on your next interactive project with this one easy trick

“Using empathy to encode planning documentation in order to maximize stakeholder engagement”

If you prefer titles that are not clickbait.

Note: This is an intermediate & irreverent post on agile project initiation and planning. If that’s not your thing this will be a long confusing read.  It’s essentially what I wish somebody told me about project planning 10 yrs ago, so it’s a bit self indulgent.  I’m always open to feedback and questions, just leave a comment. 

Empathy isn’t holding hands and talking about feelings, maybe somewhere, but that’s not how we roll in Minnesnowda.


Empathy means accepting that none of your stakeholders are going to read a comprehensively mind numbing scope of work document.   As well as nobody is interested in staying late to make inconsequential changes. And you better believe EVERYONE is billing for the 30 minute bathroom break they take to complain about you on social media.


Empathy, in the context of planning documentation, means encoding your deliverables so stakeholders are happy to engage with them.
Stakeholder engagement a major ingredient in the secret sauce behind how I routinely save big bags of money on development costs.


Which gives us the three E’s of human centered documentation: Empathy, Encoding, & Engagement.


There’s also an A, to be used only if absolutely necessary, accountability.


The goal of the Three E’s is to inform the discussions that will guide the team to the optimal path towards the project’s goals.

But what about…

But what about Agile software development methodologies?   Yes, Agile will help you accomplish more, and you will find mistakes earlier.  However, if you ask a dev team to do something stupid, and they do something stupid, they will also BILL you for something stupid.  Agile just helps you figure that out quicker, by seeing something done sooner. If we can eliminate some of the more obvious changes prior to a development iteration we’re going accelerate the teams throughput.


But what about the beautiful photoshop documents (PSD’s) the design team made?  So 2 things, first designers are rarely skilled at accomplishing business goals.  Secondly, PSD’s tend to have a host of subtle inconsistencies, and a distracting level of detail.  This will result in stakeholder feedback, but often it’s not great. Stakeholders that feel their input is important will need to find something, no matter how irrelevant, then demand it be changed.  Most folks will smile and nod approvingly, without engaging meaningfully.  The experienced dev team members will brace themselves for more of the same chaos they’ve come to expect. Usually some issues are found, but they rarely get the full understanding and stakeholder engagement necessary for early course corrections.


But what about powerpoint?  No, powerpoint is only good for extracting information from terrorists. I’ve been told this is an extreme position but I’m sticking to it. Powerpoint is fine for the overhead team members, but not for anyone adding value.


So how do we get meaningful feedback from engaged stakeholders without dropping $75 to $225 per hour on dev costs?


Well I’m glad you asked, and not just because that’s how I pay my bills, but mostly that.


The only documents that get useful feedback:

Charters, Charts, & Wireframes, all short, all written to an 8th grade reading level, & visually focused.

These documents facilitate empathy because they encode their message to fit the human condition.  The Charter sets the boundaries & goals.  Charts are the most efficient way to gain both a high level overview of business processes and granular details.  Wireframes, add a distraction free user interface to focus the discussion on accomplishing the charter’s goals as described in the charts.   The ease and efficiency of these documents radically improves the quantity and quality of stakeholder engagement.

Conversely, I’ve written some outstanding scope of work documents, but I’ve rarely gotten meaningful feedback from them.  So why write them?  Well contracts are why.  I don’t know of a development, creative, or marketing shop, especially independent contractors, that have NOT been ripped off by otherwise respectable members of the business community.  If you must have a scope of work I’ve made a Application Project Management Plan template to make the process as painless as possible.   However, if you can, don’t.

An alternative middle path is to add accountability to these documents by requiring key stakeholders to physically sign off on each document before proceeding to the next one.   If you feel like you’re working with the type of people that would always ask the professor “will this be on the test?”,  then you’ll need them to sign on the line.  If you do end up needing signatures consider a service like Panda Docs for e-signatures they really take the hassle out of getting signatures remotely.


IMHO, the most underrated project document.

The Project Charter briefly describes:

  • why we’re doing the project
  • who the primary stakeholders are
  • description of primary personas (a.k.a. the apps imaginary friends)
  • what the timeline or runway is
  • what the budget is
  • who the leadership team is, and what to expect from them

Then importantly a formal authorization for the project to begin.

Why we’re doing a project, and who we’re doing it for, serves to focus conversations on project goals.

Timeline & budget bring tasks into line with reality.

Explicitly defining team leadership allows accountability to be aligned with authority, an essential attribute of a well running project.

Keep the charter short and focus on chunking so folks will actually read it.

Project Charters are a big topic, check if your organization already as an approved template for them.  If not, be ready for a wide variety of opinions.


Flowcharts communicate processes more efficiently than words.  They quickly communicate not just the ideal path, but alternative paths, looping processes, and other tangles of complexity.

Flowcharts also focus conversations on exactly how business objectives are met.  Without the distractions of fonts, colors, logos, & images.

I’ve never produced a flow chart for a process and not had 2 things happen:

  1. the discovery and resolution of problems
  2. stakeholders visibly relax after getting a deeper understanding of how things will work.

At a very high level SAFe Agile uses value streams that can be a great place to start.  Value streams represent how value continually flows to the customer.   They are low on detail, but high on context, so they make an effective introduction.

When you’re ready to get into the weeds swimlane diagrams  integrate personas with flowcharts.   Each row represents a different persona responsible for the actions or decisions within it.

Don’t assume that anyone has memorized what the various shapes in a flowchart mean.  Include a basic key defining the most important shapes, and label things thoughtfully. Particularily around the decisions, that’s the diamond shape, where labeling the true and false lines is helpful.

Flowcharts build on the project charter to give a couple levels deeper description of what the project involves.  Crucially flowcharts encode essential business outcomes in a quick and easy to understand way, facilitating a more productive conversation.

Other charts you may find useful are sitemaps and work breakdown structures (WBS).  Depending on the project type & size these may be essential or unnecessary, you’ll find people that say both, emphatically.

While Ms Visio is the industry standard for flowchart type diagrams, I prefer & Especially for their collaborative features.


This is where the real money is saved.  It turns out humans are social animals and we learn best through play.   Charters & charts are not particularly fun, but they are a LOT more fun than a pile of paper so I tolerate them.  Interactive wireframes should be a little fun because we get to interact with them.

I prefer that wireframes, at least initially, be black & white line drawings to avoid the distractions of branding & content.  A traditional wireframe that is just a static drawing does not get the participation that we need for great feedback. Static, non interactive prototypes take approximately the same amount of time, and provide less than half the value.  With the right tools there’s just no reason to for exclusivly static wireframes, prototypes, or mockups.

Interactive Wireframes build on the charter & charts by taking that information and applying a napkin drawing level UI to accomplish what they describe.

What this gets us is something everyone on the team can play with, and point to for discussion.   With tools like MockFlow interactive wireframes are easy to make, easy to share, and easy to change.  Also as a bonus most wirefame tools also produce sitemaps, static exports, and even powerpoint slides if you find the odd terrorist.

Often with big paper scope doc’s I’d only get feedback from the most dedicated and/or paranoid of senior developers.   With interactive wireframes business subject matter experts that may be intimidated by digital are comfortable telling me I’m completely wrong and it should work like “X”.  Then I can make a edit in under 15 minutes and we can do another review cycle.   In this way I can knock out a several feature iterations in a few hours or a day or two.   Something that could take months working through a 2 week sprint iterations.

Once the application goes into production, fewer change requests can be anticipated.   This saves us money, preserves client confidence, and improves team moral because they’re not bogged down with as much rework.

Some good tools for Interactive prototypes are:
Invision primarily focused on design shops.


It tends to encourage folks to start with images that designers create, which is less useful for those that don’t use photoshop or illustrator.  Because of this I avoid it, my preference is for the whole team to be involved.


Axure RP is a more enterprise focused rapid prototyping tool, and if I did prototypes every week I’d spend the $900 bucks for the Pro version that has essential revision control and team functions.  It may be more complicated than what you want to mess with, but it’s very good.  If you have the cash to spend, and are willing to invest the time learning to use it, this is a great choice.  However, the cost & complexity will lower your participation rates.


Mockflow WireframePro– is not as designer friendly as Invision, nor as extensive as Axure RP.  It is easier to use, has a low barrier to entry, good collaboration features, and has a good free option that will let you get started.  It’s also cheap once you start adding team members.  I really like that I can involve team members easily with this tool, gets me out of secretarial work, and them faster results.


How much is just enough?

When folks are asked why Waterfall is bad, the frequent reply is a huge investment in documentation that ends up being wasteful.   Then for Agile we need to use “just enough” documentation to accomplish our goals.

So what’s just enough without being wasteful?  This is the kind of question that can start some very tedious arguments, but in my experience it’s this; only write detailed plans for as far out as you feel comfortable predicting the future.  For the most part I don’t know much about what I’m doing this time next year, but for the next month I have a fair idea.   A month is roughly 2 Scrum iterations so that’s generally what I have planned out in detail.

Now if I had a startup I was trying to get funding for I would wireframe the entire MVP and run a handful of usability studies before I presented it to investors.  I’d do this because I think it shows the entire concept in a very convincing way, and would help with pitching investors prior to having a fully functional app.  Also I think every experienced dev has been burned by a startup by now so showing an extreme level of preparation would build confidence.

Value throughput over a perfect plan, SCRUM’s guidance on time-boxes is an important tool to avoid analysis paralysis.

How will I know if these documents mattered?

If you get feedback that stings because it rings true, or feedback that feel like a punch in the gut because you made a mistake, your documentation is working.

If you get feedback that makes you want to roll your eyes because it’s so off topic and irrelevant, it’s time to change your message encoding.

If you get feedback, early, that everything looks GREAT! You’re a complete failure at engaging in a useful conversation with your stakeholders.

If you ask the dev team what they think and they say your haircut is ridiculous and you smell of elderberries, congratulations they like you and have nothing to add.

If you get useful feedback for a couple iterations, then the stakeholders seem satisfied, AND can paraphrase the project back to you in a way that makes sense. Then you’re ready to move forward.

The point of the charter, chart, & wireframe documentation is to get useful feedback as early and as cheaply as possible.   Useful feedback is usually hard on the feelings, probably for you if you care enough to read an entire blog post on documentation, and likely for other stakeholders.  However, that’s a good indication you’re getting the good stuff.

The exact implementation of your charters, charts, & wireframes will depend on who your stakeholders are, so take time to get to know them, their technical tolerances, and communication styles.

Success in the product owner or product manager role is dependent on stakeholder engagement.  You get the engagement by properly encoding your planning communication to them.   And finally you learn how to encode the message to your stakeholders through empathy.

I have a small favor to ask…
I spend between 5 and 20 hours creating these blog posts in an attempt at shameless self promotion.

If you find them helpful please share them on LinkedIN or other social networks. It really does help me find new product or project management gigs.

If you’d like to grab a coffee and talk shop, send me a email with the form on the top right