Product Spec Exercise

[00:00:00]
>> You get to write your own product spec using all the things I've taught you up to this point. I would say the best thing you could do here is write something that pertains to your work, right? If you have something already that you are thinking about, like I wanna do this, do it.

[00:00:17]
Do that. So whether that can be a personal project, maybe you can be proposing that I wanna build a, I don't know, fantasy football tracker or something like that. I don't know, making stuff up here or snowboard route tracker or something of that nature. Or if you're doing something at work that like you're about to embark on this project and you wanna work on it, write a product spec for it.

[00:00:45]
This is best because then you get to utilize your domain knowledge, which I think is usually helpful because that's what you're gonna be doing with your product specs in the future. If you're really blanking on ideas, I wrote down a few of them here, feel free to take these, modify them or write another one.

[00:01:02]
So as an ESPN fantasy sports app user, I wanna be able to click on a player's name and instantly see them playing live. As a user of Zoom, I wanna integrate my Spotify so I can play music for everyone on the video call. And as an open source project maintainer of Github, I want to be able to assign dollar amount bounties to issues, then pay someone who actually fulfills those issues directly inside of Github.

[00:01:30]
Feel free to get creative. You don't have to do any one of these here. This was just mostly here for you to get started. So what did you learn? Did anyone have any interesting insights typing into the product specs? Or is this just an exercise in futility and we're just one step closer to death.

[00:01:53]
>> Every time I approach a product spec, I'm surprised at how little of my idea gets on the page in the first draft. And maybe it is almost a great way for me, personally, to screw up finishing it. Because I'm always surprised at how the essentials don't seem to get communicated the first time.

[00:02:16]
>> I think a way that I help with that is here. Writing these two first helps me quite a bit, the goals and the non goals and the problem statement, and writing explicitly what I expect my user stories to be. Cuz that, at least for me, if I'm capturing problems my users have and I'm capturing ways to alleviate problems that my users are facing, if I get nothing else out of this I was like, here's a problem, here's how we're choosing to solve their problem.

[00:02:49]
Usually I tend to capture the part that I, that the essence of what I'm looking to do. And everything else is just mechanical of how do we go about solving the problem. Normally I don't really care how we go about solving the problem, I just care that we solve the problem.

[00:03:07]
I'm not a particular person that's married to my ideas, like I've said multiple times during the course of this course, I'm an idiot. I know that and I fully well lean into it, right? And so if I'm wrong and I know it, it means I've learned something and I'm super into that idea.

[00:03:24]
>> I think there's some option for like tenability. Cuz I think a lot of the ideas that you're generating probably could be new, I don't know. Do you, do you ever think about that or when you.
>> Can you rephrase that? Like a potentiality, like if you're coming up with a new idea, do you talk to legal about like-

[00:03:43]
>> This is something that's completely-
>> I got you.
>> We're doing here and could potentially make even more money somehow from?
>> Yeah, Microsoft was really big on that. They give you an award if you get something patented. Actually I think snowflake does it too. They have pushed that less on me.

[00:04:00]
But now I talk to legal all the time. So I would imagine that by involving legal really early in your product process, I do it just for liability and stuff like that. And generally, the stuff that I'm doing, I like to push what the terms of service allows us to do, and they kind of like rein me in.

[00:04:19]
It's kind of a process, but I would hope by those people seeing those things at those time that they'd be like, hey, is there you might have something cool and new here. Maybe we should talk about that. That's gonna vary a lot by company. I know IBM loves that stuff, right?

[00:04:36]
They just eat that stuff up. And they, I think IBM year over year gets the most patents issued to them. Something like that, which is wild to me. So, yeah, not something I've thought about, but particularly for companies that that's a big emphasis. So I think it's a great idea.

[00:04:54]
>> Do you capture like resource costs in your product spec? Like, is it gonna be like 20 developers for a year or 100 developers for five years or three months or whatever?
>> Yeah.
>> Is that one of those technical-
>> I would probably capture that in timeline, you could probably read timelines and resourcing here because those are generally correlated to each other fairly closely.

[00:05:17]
It's a good call cuz for the most part I don't capture that but that's because I only have so many resources myself, right? And people know that I'm only managing two engineering teams right now. And so I'm not really getting too many questions about who's resourcing what. It's kind of my engineering managers call, but I would capture this in like person hours or person months or whatever you would want.

[00:05:43]
This would be a good place to do it. And if that was a pertinent question, which frequently it isn't for me, but if it was a pertinent question to you, then yes, I would answer that. That stripe was a bigger question for me because I manage so many teams, but yeah.