When I hear MVP, I don’t think Minimum Viable Product. I think Minimum Viable Pie. The food kind.

A slice of pie is all you need to evaluate the whole pie. It’s homogenous. But that’s not how products work. Products are a collection of interwoven parts, one dependent on another, one leading to another, one integrating with another. You can’t take a slice a product, ask people how they like it, and deduce they’ll like the rest of the product once you’ve completed it. All you learn is that they like or don’t like the slice you gave them.

If you want to see if something works, make it. The whole thing. The simplest version of the whole thing – that’s what version 1.0 is supposed to be. But make that, put it out there, and learn. If you want answers, you have to ask the question, and the question is: Market, what do you think of this completed version 1.0 of our product?

This whole post is so good:

Don’t mistake an impression of a piece of your product as a proxy for the whole truth. When you give someone a slice of something that isn’t homogenous, you’re asking them to guess. You can’t base certainty on that.

That said, there’s one common way to uncertainty: That’s to ask one more person their opinion. It’s easy to think the more opinions you have, the more certain you’ll be, but in practice it’s quite the opposite. If you ever want to be less sure of yourself, less confident in the outcome, just ask someone else what they think. It works every time.

This piece of writing was enough to interest me in buying the book. It sounded great, even though I’ve never heard of Bob Moesta. These kinds of insight cut through so much of the cruft of making software:

Everyone’s struggling with something, and that’s where the opportunity lies to help people make progress. Sure, people have projects, and software can help people manage those projects, but people don’t have a “project management problem.”...Project management is a label, it’s not a struggle.

What kind of struggles do people have?

People struggle to know where a project stands. People struggle to maintain accountability across teams. People struggle to know who’s working on what, and when those things will be done. People struggle with presenting a professional appearance with clients. People struggle to keep everything organized in one place so people know where things are. People struggle to communicate clearly so they don’t have to repeat themselves. People struggle to cover their ass and document decisions, so they aren’t held liable if a client says something wasn’t delivered as promised. That’s the deep down stuff, the real struggles.

Your job as a leader isn’t to just help clarify thought process – but to give confidence in their thinking.

As Wade says, “You’re trying to just help them get to that realization that, ‘You know what to do.’”

They have some good suggestions on 16 questions you can ask to propel those doing the problem-solving, instead of jumping in to solve the problem yourself:

1. What do you see as the underlying root cause of the problem?
2. What are the options, potential solutions, and courses of action you’re considering?
3. What are the advantages and disadvantages to each course of action?
4. How would you define success in this scenario?
5. How do you know you will have been successful?
6. What would the worst possible case outcome be?
7. What’s the most likely outcome?
8. Which part of the issue or scenario seems most uncertain, befuddling, and difficult to predict?
9. What have you already tried?
10. What is your initial inclination for the path you should take?
11. Is there another solution that isn’t immediately apparent?
12. What’s at stake here, in this decision?
13. Is there an easier way to do what you suggested?
14. What would happen if you didn’t do anything at all?
15. Is this an either/or choice, or is there something you’re missing?
16. Is there anything you might be explaining away too quickly?

You can’t claim time on anyone else’s calendar, either. Other people’s time isn’t for you — it’s for them. You can’t take it, chip away at it, or block it off. Everyone’s in control of their time. They can give it to you, but you can’t take it from them.

The video was especially interesting.

37Signals, makers of Basecamp and ever the buckers-of-trends, wrote this piece about why a monolith architecture (vs. the trendy micro service) is the right technological solution for them. At a more general level, they make this important observation:

The patterns that make sense for organizations orders of magnitude larger than yours, are often the exact opposite ones that’ll make sense for you. It’s the essence of cargo culting. If I dance like these behemoths, surely I too will grow into one. I’m sorry, but that’s just not how the tango goes.

This is true of not just technical patterns, but general organizational approaches too. But that you shouldn’t run HR like a 50,000-person company when you have 50 seems obvious to most though (with some exceptions)