BLUF, Problem Statement, & Goals

[00:00:00]
>> We had a whole section on this. I'm not going to spend a bunch of this or spend a bunch of time on this. I write this last, the BLUF, right? Usually I'll let an AI client take a run at it, like ChatGPT. Usually for me it's Notion, cuz I can use that when at work.

[00:00:17]
And say like, hey, summarize my entire product spec into two to four lines. And it'll spit something out. I'll probably spend a half hour tweaking it, and that's usually a good process for me. But I aim for that executive summary. It's like, if you land on this product spec for the first time and you read just that and you leave, that I got my point across.

[00:00:37]
That's my goal. I don't know if I always get there. Sometimes that takes more than four sentences. I mean, all these rules, again, are designed to be broken, but less is more here. The more concise you can be about the problem statement, the solution, and anything else you need to be in there, the better you are.

[00:00:58]
Okay, the problem statement and user stories. Here whatever I didn't say in the BLUF, I'll blow that out. I'll put a couple paragraphs here. This is a problem. We found this problem here. So put a little bit of credibility appealing in there. And here's our solution, here's why we think this is going to work here's the research that we did on that here's a bunch of links if you need to go to those things.

[00:01:25]
And I try and land on what here. I'm sure many of you have heard the minimum viable product, right, let's get the MVP out there. I don't quite always agree with that. Sometimes I do agree with it. I try and go for the minimum lovable product. Because sometimes when you go for the minimum viable product, and to explain myself here, the idea between behind a minimum viable product is that what is the minimum set of features that we can launch here and have it still actually function as a holistic product?

[00:01:59]
Frequently, that has you stripping out the thing that actually makes your product interesting and it doesn't quite accomplish what you're going for, and therefore you're not actually proving what your hypothesis is or isn't sometimes, right? So someone used this term, minimum lovable product. Whereas, let's get the core set of features plus the differentiator that we need here for this actually to be holistically proving to ourselves this product Specter is viable to go forward or it's not viable to go forward.

[00:02:28]
You might argue that that's the viable part of it, but whatever I like this term so I stick with it, minimum lovable product. So find your balance. Yeah. I tried to preserve where possible what makes a product special and ruthlessly cut anything else out. Anything that's optional, tangential, only affects some of our users.

[00:02:54]
Those are the kind of things that I try and cut out. So try and find whatever your balance is there. Okay, goals and non-goals. This is actually more useful for the non-goals section. Here, I try and say, like, I'm trying to do this, I'm trying to do this, and I'm trying to do this.

[00:03:17]
And if you don't put in the non-goal section, someone's like, well, did you think about this? Did you think about this? Did you think about this? And when you definitely already have, because it's obvious, and the person's just trying to hear the sound of their own voice, right?

[00:03:29]
So the non-goals, like we are explicitly not working on this, we're not shipping this and we're not going after this demographic, right? So a good example this is, hey, we have this dependency on, I don't know, like GitHub, right? And you're building this entire thing about integrating with GitHub.

[00:03:49]
And in your non-goal section, you might put like, we're explicitly only chasing GitHub here, and we're not thinking about BitBucket, we're not thinking about GitLab. We're not thinking about any of these other services right now, we're just focusing on GitHub because we want to try something first before we fan out to everything else, right?

[00:04:08]
Non-goals would be a good place to put that, as like we're not trying any of these other things until we prove that the GitHub integration works well first. This is your guard against scope creep, which some of you might have heard of but let me explain to you just really quickly.

[00:04:25]
The scope, in fact this is what goals and non-goals are doing. You're basically defining the scope of your project. And scope creep is the unfortunate thing where things kind of just keep seeping into your project. It's like, we should add this. We should add that. We should add Bitbucket, we should add GitLab.

[00:04:41]
We should add add self-hosted Git, we should add SPN, we should add Mercurial, right? And all sudden, your project which was very tight and very focused becomes blown out, and what was supposed to take a month, that's now going to take a year right? You would call that scope creep.

[00:04:58]
This section is basically you playing goalie trying to prevent scope creep on your project, right? You're trying to preemptively block things and then when someone says later, that's something you didn't think of, you can say, okay, let's add that to the non-goals, because I don't wanna do that right?

[00:05:14]
And so it's kinda your ability to prevent that from continually coming up.
>> It should be easy, they say. You did it in the last project. Why not do it for this one too, right? The same filters, it should be easy. I'm like, maybe no.
>> Yep.
>> For you.

[00:05:31]
[LAUGH]
>> Put it in the non-goal section, make them fight you on it. And typically, people will, as soon as you list it in there, it's like, hey, here's your feedback and I put it in the spec of stuff that I'm definitely not gonna work on. Usually they feel fulfilled that they feel heard, right?

[00:05:48]
You heard it, you thought about it, and you decided it wasn't what you wanted to do. For many people, that's enough. Right?
>> File that right here in the shredder.
>> Yeah, you, yeah you can call this the shredder if you want, right. I like that. Maybe don't call it the shredder though, just implicitly.

[00:06:08]
Key metrics. We've talked about this already previously. This is where you're actually going to list out stuff that I intend to affect. Here's how I'm measuring success. And if I don't affect these things, this is what I would consider a failure. So I wrote down some thoughts here of things that I think about when I write my product specs.

[00:06:33]
MAU, which is what a lot of people call monthly active users. MAUs, MAUs, or DAUs, daily active users is a good metric that a lot of people track. I imagine many of your companies track how many users are active at least once a month, and they consider those people active on your product.

[00:06:52]
A couple of things. It is a good metric. You should track it if it applies to your business. However, it is not always 100% the end-all, be-all of your product. If a user uses VS Code once a month, would you call them deeply engaged in VS Code? No, probably not, right?

[00:07:13]
They're not certainly not your most power users. Once a month is not that much for a code editor. Is once a month good for a, I don't know, like monthly budget tracker? Yeah, it's probably actually pretty deeply engaged with the budget tracker, right? So it's gonna be super contextual to whatever you're working on.

[00:07:38]
Here's an example that Microsoft did years ago. They had a pretty big dip in MAU on Excel and they were wondering why it is. And they found out that a lot of these businesses had moved to quarterly finance reports as opposed to monthly reports. And so they had these like huge spikes every quarter.

[00:08:00]
And they found out it was just users that were opening their, you know, reports, reading them and closing them, and then not opening it again until the next one. Is that an active user on Excel? It's not not an active user. For those users, probably that's as engaged as you're gonna get with them, right?

[00:08:18]
And so they actually had to come up with a quarterly active user metric to make sure there's all right, are we capturing those people that are only ever going to open any spreadsheet quarterly, what are we doing for these most casual of users, right? Because monthly, like they had, the spikes were really weirding them out and it really affected their metrics in strange ways, but once they normalized across the quarter, it got much easier for them to interpret their data, right?

[00:08:45]
So, think about multiple axes of active users. So, specifically for VS Code, we looked at people that opened once, opened twice, and opened seven times for, like, lightly engaged, engaged, and deeply engaged users across a month, right? Because we figured, like, if you're opening seven times a month, you're using enough VS code that we're satisfied with how active you are.

[00:09:12]
>> Can you use like statistics to kind of create analysis around that average use and.
>> Yep. There's all sorts of stuff you can do around it that I am not qualified to talk to you too much about. [LAUGH] Yep, absolutely. And we have data scientists that look at it.

[00:09:33]
Yeah, we talked about this previously but a CSAT is the metric you're looking for, plan for the long tail it takes a long time to affect CSAT. Let me tell you from years of experience doing this across multiple companies, CSAT takes a long time to bear out. And then, yeah, pair CSAT with something more trackable, more immediate, that will serve you well.

[00:09:54]
If you're doing a project that, and your only metric is CSAT, it's not gonna be a good project. I don't think I've ever seen that before. Your project should always include team metrics. And if it's not including team metrics, it should always include company metrics. So some of the products that I have to do today as part of my job, I'm helping sister teams with their metrics.

[00:10:19]
That's fine. Just call that out. And we do ladder up to team organizational metrics, but we do not ladder up into my metrics. It's fine, right? Team dependencies are a thing. We have to all be team players, so just call that out. And if you are not laddering up into a core metric, be very explicit like, we're doing these things, and here's why we're not contributing to the company goals.

[00:10:46]
Now, that can be a bet, right? I've seen things like that. It's like, hey, we're going to try this thing and we're betting that this could eventually become a core metric of the company. That's fine. Just talk about it. This one's hard. If you know specific goals, we want to grow by X, we want to slow tickets by X percent, we want to cut spend by X percent.

[00:11:07]
Call that out. You're not always going to know that. I try and at least always get numbers in here eventually. Some of the things I have to kind of establish a baseline of like, OK, we're doing this. What's our numbers now? OK. And then once after the project is launched, like, OK, we actually have a goal to get here.

[00:11:27]
But I do try and get these numbers in here eventually. Even guesses sometimes can be okay. Sometimes guesses can't be okay, right? So, just play that by ear. Sometimes utilization is not actually the thing you're looking for. This is what's counterintuitive to me. It's okay to have people try something, like it, and move on.

[00:11:54]
So just one that hadn't popped into my head because I was using it is a project called Compose. Kompose is a project that takes a Docker compose file and turns it into a Kubernetes configuration. It's a project designed to get you started, right? Now, I would argue, the most successful use of the Kompose project, with a K here, is that you try it once, and be like Kubernetes is awesome, and then you just write all of your Kubernetes config files by hand now, right?

[00:12:27]
You have successfully migrated from Docker Kompose straight on to Kubernetes and you never use Kompose again. The most successful use of this is one time. So how do you track that? It's gonna strongly depend on, for this particular case, I would just track like one-time usage and then also track, you know, Kubernetes adoption.

[00:12:48]
And if I can correlate those two, awesome, right? But sometimes that's not totally possible. But, yeah, just keep an eye on what are you actually trying to affect? What is your actual goal for the project? If you have someone that uses Kompose all the time you might be asked like how do we get this person off of Kompose onto Kubernetes directly?

[00:13:07]
Do we want to? I don't know.