How to account for context with tools, goals, and scope.

Three articles from people I follow that share good advice for dealing with context when building products.

First off, thanks to everyone for subscribing to and reading InsideProduct. Whether you’ve been here a while, or just recently subscribed, I appreciate you following along every issue.

My family and I are spending the week in Hawaii for some college basketball and the other things you typically do when you’re in Hawaii.

One of the things I typically do when I’m… anywhere… is a bit of reading. It just so happened that in my reading this week were a few good articles that share some interesting perspectives.

In their own different ways they explain the importance of context, whether it be picking your tools, picking your goals, or picking what you build.

The MoSCoW Debate: Why Tool Effectiveness Must Consider Context

It’s never the tools.

It’s about the tools in context.

The right tool in the right context is amazing. The right tool in the wrong context is not.

This all sounds self evident. Except, while absolutely true, it is deeply unhelpful because it means that all tools are magically excellent and that all issues with tools are due to user error. A somewhat awkward starting point when the whole point of using any of these tools in the first instance is to get stuff done within a context. Tools are only ever used within a context.

Hannah Pearson-Coats explains why the excellence (or otherwise) of a tool in the absence of context is simply theoretical, and then proceeds to explain why the prioritization technique MoSCoW sucks.

Goal-O-Rama

John Cutler recently worked with a team and noticed their goals looked identical—like Target Goals. John encouraged them to mix things up and mix/match different types of goals. They seemed to enjoy the exercise. John shared some goal types they ended up with, along with a personal health and product example.

Your customers hate MVPs. Make a SLC instead.

Product teams have been repeating the MVP (Minimum Viable Product) mantra for a decade now, without re-evaluating whether it’s the right way to maximize learning while pleasing the customer.

Well, it’s not the best system. It’s selfish and it abuses customers so you can “learn.”

Jason Cohen suggests that instead of MVP, make the first version SLC: Simple, Loveable, and Complete.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent