Rollback Criteria, Timelines, & Mockups

[00:00:00]
>> So rollback criteria. This is strongly tied into metrics. I'll typically identify this is the core metric of the project. If we don't affect it in these ways, in this time frame, then we will rollback. In other words this is, when do we stop trying? Now usually what I have is, we expect to affect these metrics if we see low utilization, low uptake, and we see our metrics not moving in the way that we want them to.

[00:00:36]
Then in three months on this stage, we'll get together we'll have a chat, see if we can pivot some way and improve or change the experiment some way. And then after six months, if we haven't affected it in the way that we want to, we'll cancel the project and we'll rip out the code.

[00:00:53]
That's generally my process. I try and give us a checkpoint to try and fix it. Now, if you say that I'm going to rollback, one, have a time-frame, and two, schedule the meeting right away, right? So if you launch a project and you say, if this isn't working in six months, we're not gonna do it.

[00:01:12]
If you do not put that on everyone's calendar, you're all gonna forget about it, I promise, right? No one's thinking that far in advance. I am literally just thinking about my next meeting and I have nothing else in my brain, right? Everyone's the same way. So use your calendar there to keep you honest.

[00:01:30]
It also helps you identify how to unravel a project, right? What do I have to do to move this out? Some of these are gonna be called trap door decisions, not a term I came up with, but it's basically a one-ways door, right? If we do this project we're going through a door and we cannot go back.

[00:01:50]
And it's good to just talk about that there, right? We're gonna sign a ten-year contract if we go through this door. But we can't under sign the contract, right? We're kinda stuck in this world after this. That would be a trap door decision, right? Or we're gonna build a new thing totally on top of ChatGPT and we're signing a contract for that.

[00:02:09]
And if we get a year down the line, while everything we've built is on top of ChatGPT, it's really hard for us, or very expensive for us to switch. Those are kind of things that we have to say, we can't really rollback here, this is a bit of a trap door, things like that.

[00:02:27]
So, And sometimes it's good to just acknowledge that even if we don't see uptake on this feature or uptake on our metrics, we still think this is a good idea, we're gonna keep it around, right? I'm trying to think of what would be a good example of that.

[00:02:48]
Let's say you have a project to move from Heroku onto Google Kubernetes Engine. You could say in here, our goal is to lower our time to first paint and time to first interactive for our website. And even if we don't necessarily meet that metric with our first migration, we still think we wanna be on GKE.

[00:03:13]
So we're not gonna rollback even if we don't meet these metrics at first. We're still gonna keep moving forward because we think this is a future bet that we wanna keep going with, right? Another good place to identify those kind of decisions. Okay, this one's for all the executives out there, when?

[00:03:31]
When am I gonna see it? When is it gonna get done? If you don't know, guess, right? And just say, hopefully you have a good product process in place that says, hey, we're two months into this project. We had a four-month goal, we're gonna slow down. And a way to communicate that, but here you should just guess where you think things are gonna land.

[00:03:53]
And obviously you should work with your engineering partners to figure out what that is, Okay? Designs and mocks, and we'll go over this a little bit, actually kind of here in just a second. So let's say you're designing a new sign-up process for your particular project. You should just go try it.

[00:04:15]
Go try and design what you're proposing here. Anything that you can go to visually represent to people, this is what I'm trying to tell you, right? I do this all the time, and they're terrible, right? All I do is I go and I browser hack. Buttons in, and I change button colors here, and I Photoshop things in, and I'll draw on it.

[00:04:36]
But anything I can to do to represent, this is the anticipated UX flow of where I wanna go, just drives home your point so much more. So I'll show you on the next page. I actually did one for you. Don't make these perfect. Don't spend a lot of time on these, right?

[00:04:54]
What you wanna do is communicate your point and nothing more. Things don't have to be centered. They don't have to be the right color. They just have to communicate, these are the kind of things that I anticipate happening. So I use emojis, I use Photoshop, I use macOS Preview.

[00:05:08]
I'm scrappy as hell with it. I'll literally design it on a piece of paper and take a picture of that piece of paper and put it on Google, right? All those things apply here. I use Google Drawing all the time for this kind of stuff. If I need a little bit more fidelity, I'll go with Balsamiq, which is another program that lets you wireframe things.

[00:05:31]
But usually, that's even too much fidelity for what I'm talking about. I'm talking about be real scrappy with this and be really fast about it. If I can't make my point in Google Drawing, I will go try it in Balsamiq. Or I'll just go to the designer and have them help me get something done really fast, cuz I'm not very fast at designing, so.

[00:05:49]
When do we take my crappy mocks and turn them into high fidelity, or even wireframes, or something like that? Let me give you a kind of a multifaceted answer there. One, I'm gonna say, it depends on how important the designs are to the decision. Cuz when I'm making these product specs, it's before we've approved them for work, right?

[00:06:13]
So I need to make the products spec. We take that to a group. In my company we call that a product review or a UI review. Strike call them something else, Microsoft call them something else. But some bodies like, here is a product spec, everyone's read it, yea or nay, right?

[00:06:31]
So generally before anything gets to that point, it's just the crappy specs that I have put together myself. Unless those designs are critical to me communicating the point of what the project is. In which case I'll ask for wireframes, or at the very most I'll ask for low fidelity mocks.

[00:06:54]
Which is something that a designer would do, but a designer would do fast, right? I would never ask them for polished high fidelity mocks until we're actually gonna go to press, we're actually gonna build something. So Figmas generally are for low or high-fi, or high-fi [LAUGH], low fidelity or high fidelity.

[00:07:16]
But it'll depend on the project, right? Generally I wait until after it's been approved and then I'll ask the designers to work on it. But I usually have constraints in how much design time I get from my designers. So I try not to bug them until I really need them.

[00:07:33]
If I had more design free time, I might ask them for more things. Once those designs are done, I would say, delete all of your crappy designs and just link to the Figma doc or whatever that is as well. Technical concerns and outstanding questions. If I have what I call big rocks, this is what I'll put here.

[00:07:54]
So, hey, we're proposing this project, and I don't know if x is possible, right? So I'm proposing that we're gonna do this sort of video processing for our app, but I don't know if Amazon Web Services thing works for this, right? Now typically I would say just go find out if it works for it.

[00:08:14]
But maybe you have some of those unanswered questions. Or I have this dependency on a sister team and they're unable yet to commit to me that this is what they can do, right? Here's where you list those almost existential threats to this project. You describe risk here, essentially.

[00:08:33]
These are useful because people can then read the doc and say, I have your answer, or I can help you find out, or here's additional context that you may not have had, right? I do not go in and solve the little rocks here, right? Paper cuts or things that I'm positive I can work around or things I'm sure enough I can work around.

[00:08:53]
So don't make this a trillion lines long of every reason that this can't work, or could possibly not work. Because you're gonna end up convincing a bunch of people that your product spec is bad, which is not what you want, right? This is another thing where you can basically, people are gonna come to you and say, hey, did you think about this?

[00:09:15]
And you have a bit of inoculation theory here where you can say, hey, check out my doc is actually already at the bottom there. I already thought about that. Okay, Appendix, I end up just putting a lot of other stuff in here like, here's graphs that justify the project.

[00:09:32]
Here's a competitive analysis, I would put that down here if it was applicable. Any other section that would apply to any random spec, that'll go in the appendix. All right, that was a lot of words, but that's kind of my exhaustive process that I put into writing a product spec.