Use a P.H.E.E.L. blog for better team communications

TLDR;

Projects are much healthier when there’s a single, unambiguous canonical source of truth for all the work we’ve done. We call this a "PHEEL" blog, which is to say any work product which might fall into the following categories:

• Plans,
• Hypotheses,
• Explorations,
• Experiments, and
• Learnings

Ought to be delivered here. Depending on the team, you may elect to add "Decisions" to the list, or manage them in an ADR.

This record ought to be 1) immutable, 2) chronological, 3) narrative, and 4) comment-able, so we often choose to use blogging software. The critical factor is Team Adoption: this only works when "post to the PHEELblog" becomes the default vector for any and all deliverables; if it feels like extra work, it won’t happen.

Use a P.H.E.E.L. blog for better team communications

TLDR;

Projects are much healthier when there’s a single, unambiguous canonical source of truth for all the work we’ve done. We call this a "PHEEL" blog, which is to say any work product which might fall into the following categories:

• Plans,
• Hypotheses,
• Explorations,
• Experiments, and
• Learnings

Ought to be delivered here. Depending on the team, you may elect to add "Decisions" to the list, or manage them in an ADR.

This record ought to be 1) immutable, 2) chronological, 3) narrative, and 4) comment-able, so we often choose to use blogging software. The critical factor is Team Adoption: this only works when "post to the PHEELblog" becomes the default vector for any and all deliverables; if it feels like extra work, it won’t happen.

INTRO

Building digital products is harder than it looks. You’re working with bits, not atoms, so success often hinges on a product- and discovery-focused "Building the Right Thing" than on an engineering-focused "Building the Thing Right". Which is to say, lots of iteration and experimentation is key.  As the team iterates (i.e. Trial-and-Errors) its way through lots of Wrong Things, its critical to stay focused and not drown in a wasteful excess of intra-team communications. A P.H.E.E.L. blog is a great way to cycle through the Build-Measure-Learn loop with minimal waste.

What are PHEELings? INSERT THERAPIST JOKE. Plans, Hypotheses, Explorations, Experiments, and Learnings. How do we make a PHEELings blog? Really, just two things:

• A working agreement among the team,
• a bit of old, unsexy technology (a blog!)

The Working Agreement

It’s critical that the team trusts the blog. It needs to be the Canonical Source of Truth for all of the PHEELs. That means each team member needs to be a bit of a prima donna: if anyone ever tries to share a PHEELing in any way other than the blog, they need to be told, kindly, "no". Did someone email you the  plan for this quarter’s roadmap? A new feature idea? The results of a user testing session? Insights gleaned from the latest competitive research? Push back. "Sorry", you say. "I can’t wait to read it, but this is too important to get silo’d away in an email chain. Can you post that to the blog and email me the link?".

So what do you need to do? This is the tough part: it’s time to build a habit (and accountability with your teammates). Any time you’re writing something down that you intend to share with someone else (and "someone else" could be Future You, a few months down the line), ask yourself:

• Is this a Plan?
• Is it this Hypothesis?
• Is this an Exploration or Experiment?
• Is this a Learning?

If the answer is "yes" to any of the above, stop what you’re doing. Do not send an email. Do not share a deck. For the love of all that’s holy, do NOT put a PDF on Sharepoint.

DO write it up. DO author the deck. DO render a PDF. Use the right tool for the job. Use your right tool for this job. This is one of the great advantages of this Technique: it plays nicely with whatever tools or modes you’re already using. So: do whatever you need to do to memorialize the work you’re doing and the decisions you’ve made. And then, slowly, calmly, confidently, amble your way over to that blog. Compose a post with a bit of context, the memorialization of the Plan, Hypothesis, Exploration, Experiment, or Learning you want to capture. Maybe add a little wrap-up or hook for next actions. The context and wrap-up could be as little as a sentence—you’re just trying to make it easy for a reader to orient themselves to the real work, the PHEEL, and why it’s relevant to the project and worth talking about. But wait! Your work isn’t done; metadata is a first-class concern and deserves our respect and attention. Tag the post with any appropriate PHEELs. Sip your coffee. Hit "publish". Smile.

(Don’t forget to email a link to the blog post if necessary to share it out).

Party like it’s 1999

Wait, it’s <s>2020</s>2023. Why are we using a blog? Great question. We’re solving a few problems here.

1. Creating a Canonical Source of Truth
2. Defaulting to Narrative (Because that’s how humans process information)
3. Protect ourselves against the ravages of time. Defeat a wiki’s "This Is Where Good Ideas Go To Die" problem. By being chronological, a blog gives readers a fighting chance to determine "is this still relevant?"

Canonical Source of Truth

Metcalfe’s law teaches us that as team size increases linearly, the amount of communication increases exponentially. Translation: OMG your inbox is overflowing, and did you say I should review report-final.pdf or report-final-FINAL.pdf and do you know if Alex has that deck? Maybe Billie can find it?

Defaulting to a communal shared space solves this whole class of problem. There’s only one place to look for things, and everyone knows where it is. Bonus: when new members join the team, it’s real easy to help them get up to speed with 1) the current thinking of the team, and 2) how we got there.

Defaulting to Narrative

What’s the difference between writing for a blog and writing an email? It’s subtle, but the different audiences shape the writer’s tone and frame. When we write email it can range from personal to formal, from laying out all the context to the in-jokes and shorthand of an experienced pair. Blogs are a little different. There’s always the implicit specter of a new reader, someone who needs to be oriented. No matter how unconsciously, we put together a story. We lend it structure to make it understandable, because that’s how humans make sense of the world. Because we’re making it more accessible to new readers, we’re future-proofing the work against future versions of ourselves returning to the post six months hence, having lost the context we now keep in our head, helping Future-Us have confidence that while our understandings of the product may have moved on, this at least is evergreen: our memorialization of our thinking at this point in time.

The Ravages of Time

"Sure", you say. "This all sounds great. In fact, my team is already doing this. Would you like to see our wiki?"

No. I’ve already seen it. And it’s the wrong tool for this job. A wiki is great when you’ve got massive effort, redundantly and consistently applied. It takes a village. The editor community acts as an immune system for Wikipedia. False, irrelevant, or obsoleted facts are reliably addressed. We go to Wikipedia and find it to be a trustworthy resource and a shining human accomplishment, sharing and scaling knowledge, retiring the ivory-towered Brittanicas to the past with a "thank-you" and "goodbye".

Your office isn’t that.

It almost never makes business sense to apply that level of effort to an internal knowledge-store. When wikis are used for intra-team communication, articles often go stale, go unwritten, or go missing. It’s difficult to adjudicate conflicts between versions or contradicting information. There’s no feedback loop to flush out incorrect or outdated information. We go to a wiki for answers, but we’re invariably haunted by doubt: "it says this on the wiki, but is it [still] true?"

But a blog? Each post has a date on it. Is the post recent? It’s probably still relevant. Is it real old? Maybe ask around a little and see what the latest thinking is. Easy-peasy.

Get in touch with your P.H.E.E.L.ings

It’s not hard, but most people need a bit of practice to get into the habit of recognizing P.H.E.E.L.ings.

Plans

This is any decision you’ve made about what to do next. It probably needs a finishing condition ("we’ll know we’re done when…") and some sort of time-box. It could be as loose as "we’re planning to interview users until Charlie feels like we’re on the right track" or as formal as a 112-page Go-To-Market plan the team’s spent the last four weeks building.

Hypotheses

"What’s the least amount of work we can do to learn or get something?"

Not just product-market hypotheses; also problem-solution hypotheses. I find Lean Hypotheses to be a useful framing device for all sorts of products and problems:

"We believe [TYPE OF USER] has a problem [DOING THING]. We can help them with [OUR SOLUTION]. We’ll know we’re right if [CHANGE IN METRIC]."

Exploration & Experiments

Ok, maybe there’re two "E" words because "PHEEL" sounds better than "PHEL"…but in practice, I find "exploration" well-describes less-formal explorations (conversations, musings, comparative research), while "experiments" connotes a bit more rigor (user tests, prototypes, interventions).

Learnings

First there’s information, then there’s data, then there’re insights. "Learnings" is a synthetic category: anything valuable (failures and "I’ll never do that again!" count!) and worth sharing with the team and future-you.

Setting up your P.H.E.E.L. blog

Pretty much any blog-ish software will do. You’re looking for a few critical features. It oughtta be:

1. Chronological
2. Immutable
3. Password-protected

I haven’t found any software that I really love; the password-protection is a bit hard to find in free / light-touch software. Got any suggestions? Share them in the comments!

Advertisement