Module Description:
Ubiquity Extended Team member Nathan Ackerman shares his view on how product and engineering leaders can better manage the product development process by not rushing to development and instead focusing on requirements definition upfront.
Full Transcript:
Hello, everyone. Welcome to our Ubiquity University session on "Nailing the Mindset for Product Development." Today, we have Ubiquity Extended Team Member, Nathan Ackerman, who's gonna talk us through his views on this subject. Nathan is currently SVP of Engineering and CISO at Signifyd. Prior to that, he was Director of Devices at Amazon and founder and CTO at Owlcam. Thanks for being here, Nathan. Excited to hear what you have to share and to dig into some of these ideas you have around product development and thinking it through before jumping right into building something. So welcome and let's get started.
Thanks, Sunil. Sounds good. When we talk about building things, I would encourage everyone to think about it in the following way, really an execution framework. Whether you're building hardware or software, you'll be judged and you'll judge yourself really on three things at the end of the day, which is quality of what it does, cost, and schedule. This is kind of the key framework to think about evaluating any project, whether it's yours or someone else's. And when you manage projects, there's this process where you understand, "What am I need to be built or what am I building?" that also informs, "How I'm gonna do it?" which then also informs, "Well, what can I really do?" Asking for things that can't be done is really difficult. And there's an iterative loop between knowing what I need to build for my customers and what can be done in the design. And in this context, requirements is really about understanding "What do I need to build?" And the design is both a software design, a hardware design, but it also might be a visual design like in Figma. And it's really important to get both the "What am I going to build?" and "How am I going to build it?" decided and agreed upon because that allows you to understand and say, "Yes, I can do this at a cost and a quality and a schedule, and I can move into execution." And there's a lot of time when it's really unclear, are you on the left side of this diagram or are you on the right side of this diagram? And the best companies in the world take time to align and agree with everyone involved on everything on the left side of exactly what's gonna get delivered and how it's gonna get delivered before they start taking on the task of executing. Just the task of executing is hard enough, but when you pile on the need to define what I'm gonna deliver and how I'm gonna make it at the same time, this is where you oftentimes get into trouble, which leads to a negative spiral of swags, estimates, and the eventual conclusion of most people that you just can't estimate software or projects. This isn't right. Yes, it's true, you can't estimate software and projects if you don't know what you're building, but what I've seen and what other people have seen who have been successful here is that if you take the time to understand what you need to deliver and you take the time to understand how you're gonna do it, you can repeatedly manage the execution and you can manage it yourself and you can be repeatable and you can understand exactly what you're building.
So Nathan, what would you say if a five-person seed-stage startup said, you know, "Yeah, that's great, but we don't have time. We gotta hurry up and build. We need to hurry up and get to execution." What's your answer?
I hear this a lot, and the short answer is, "Build what?" You know, again, if I were to ask you to build something, the first question you would ask to me is, "Well, what am I gonna build?" And so, the way I think about it is, unless you're really clear about what you're going to end up at the end of the day, and unless you're clear about do the people building it have an idea and are they capable of building it, then you're really not ready to build. And this feeling of, "I just need to hurry up and build" really comes from, I think, a bit of inexperience. Whenever, you know, I've had that feeling, you know, very distantly in the past, you end up taking way longer and ending up with, like, a lesser result. What I find time and time again is if you take the time upfront, you are faster in the end. When I hear that people say they don't have time to take time to write down requirements or plan out the design, what I find is they're gonna do the design multiple times and end up taking much longer. It's kind of like if you've ever tried to do a home project and you want to go to Home Depot. If you take the time to plan out how many screws and you measure out the sizes, you're gonna go to Home Depot once. And if you don't, again from experience, you're gonna go five or six times and you're gonna feel like, "Gee, there really could have and should have been a better way." And the answer is that there is. If you're working on a project with literally more than one person, making sure that everybody involved is super clear on what the right outcome is and making sure that you have an idea and you're confident and that you can build it, then the rest is just executing. And just time and time again, that leads to better outcomes because again, like I've said, there are enough problems in just executing that you don't want to conflate them by also having a change in design and/or a change in requirements. When you think about organizations of any size, there's a phrase that I think gets thrown around which is, "I love it when a plan comes together." People need an operating plan in their head to operate independently, again, for any group of people greater than one, and not just for two people, but for five people, for 10 people, for 1,000 people. Marketing needs it, finance needs it, engineering needs it, product, the CEO and the board. Everyone has to have some mental model of how things are gonna come together on roughly a timeline. And again, the framework for execution says this. It says that people evaluate projects on cost, schedule, and quality, and that's really the three variables that people talk about. And so, an org needs to be able to talk about what it's gonna get done, when it's gonna get done, and also how much it's gonna cost. And so, this kind presents a problem and also an opportunity. And the problem is that everyone needs longer term plans than you've had had time to detail out the project definitions. Like we talked about, if you avoid planning, if you don't write requirements down, if you don't have a plan before you start something, you're, generally speaking, not gonna be successful. And so, when people ask you for the big three of schedule, quality, and cost, you're guessing, you're estimating, you're swaging, and you're gonna be wrong and you're gonna lose trust, and it's gonna be painful. But yet at the same time, for more than one person to operate, you really have to have something in place so people can go about their day-to-day lives. And for larger projects, this is how you connect and actually come together and deliver multiple big things, kind of, at once. And so, the question is, how do you manage this? I think a lot of things, especially younger companies and younger in career folks, you know, when you have to deal with boards and executives, it's really true that either you manage the situation around you or that situation is going to manage you, and it's very painful when the situations end up managing you. And so, there's really two different answers or two different pieces of technology, if you will, to talk about this, and I think about them as terms of zoom levels. It's important to have a plan, and this is what a roadmap is. It's a high level plan informed by capacity, and I'll talk about that in a minute. But then separately from the high level plan of this is the intent for things to happen in what order, individual projects need to be managed. And when you manage them where you're talking about requirements and you're talking about the design and the implementation details, at that point when you have both of those agreed upon, then you can make commitments and track to those commitments and you'll be successful because you'll know what you're building and you know how you're gonna build it, which lets you just focus on doing the actual work. And it's super important to have precise language and be really clear with everyone, the board, your staff, everyone involved in the organization where you are and what you're talking about.
Nathan, it's interesting to think about, you know, as a board member, I ask for commitments all the time but in a funny way. A commitment without a really well-thought-out plan behind it is a very loose commitment, right? It's almost like I want that as much as the company does, to have that really thoughtful roadmap that backs up what they're saying and that they can hit the three parameters you said the way that we want to in that timeframe.
Yeah, we all want that, I think, but it's about how do you do enough in the moment to make progress for the next four to eight weeks and how do you kind of do just in time the right level of work. And so again, I think this is different for software and hardware and we'll kind of talk about that. But if you take a software-only lens for a second, your commitment is only as good as you're planning. And I think the valley in every area is kind of littered with bodies of people who've learned that the hard way. And so, you have to have a plan and the bed of the plan, the closer and higher likelihood you'll be to making your commitment. At the same time, you've gotta have a North Star and you gotta know where to go. And so, the trick is having a roadmap and talking about that at the right level and having commitments at a project level and really managing expectations. And as much as some people want to be said, "Look, this is the plan and this is the commitment," that's really the language and the distinction that I think is important to establish when you're talking with the board and really help manage the situation. And that's really kind of how you kind of need to operate because there are gonna be more understanding of certain things that you've taken the time to understand and build, and then there's gonna be other things that are more aspirational and directional and that we will spend time on but we don't have yet. And so increasingly, you can get skill on talking about your plan, and I'll talk about that in a second, but it's just really important to understand, you know, back to one of my earlier points, "Have I spent enough time making sure I'm clear on what I'm delivering and how I'm doing it?" If yes, commitments are very straightforward. If no, what you're talking about is an intent and a plan, and it's really time to get to getting so you can make a commitment. So in terms of building a roadmap, a hardware and software roadmap differ, especially for smaller companies, because most of the company is going to be focused on like one product for hardware, and that's gonna be it. When it comes to software only, or once you've shipped a hardware product and are focusing on software improvements, you're gonna have more features, and those cadences are naturally gonna be shorter than it is to, say, spend nine months in shipping your first piece of hardware. The process is really the same. Generally, it's stack rank the needs and wants of the business. Second, determine what your unit of capacity is. Do you have one team that can move from feature to feature? Do you have two teams? How are you staffed? How do you think about work? Do you have one hardware team that can build one hardware device? Do you have two in parallel? Then, schedule them on a calendar according to the assumptions and what you think the project size is going to be. And lastly, update regularly. I think one of the other presentations you had, Sunil, talked about updating the board on a cadence and using really high level graphics and icons to show what moved and what changed, I think that's excellent. And I think having a culture where you are updating this and reviewing the roadmap, it's the right practice, it keeps everyone aligned, and it reinforces this notion of, when we learn things, we can actually make changes and adapt to them. And again, just a last point, I think hardware and software differ here just in the sense of hardware is gonna be much more focused on kind of a longer single project, which is really about the device, where I think software can be broken down into kind of features with faster loops. So building on that together, I think in terms of a hardware roadmap, I can't stress this enough, you don't have a schedule until you have a design, just like we've talked about, and this has been never more true than in hardware. And what we've found and I think what people have seen is if you design it while you're scheduling it and figure this out on the fly, you never hit a schedule. But what we've seen is if you take the time to design it, then once you have a design, the process for producing hardware and developing and executing hardware actually can be repeated reliably. And so this is, for example, a sample roadmap. Again, once you have a concept that makes sense of requirements and then first principle prototypes and the hardware available and you can do everything you kind of fundamentally need to know, then you can go through these steps and very reliably ship high quality hardware. You know, for example, tool release taking between, you know, eight-plus weeks. And then these milestones of P-EVT, EVT, DVT, PVT, again, the best teams in the world did this in six weeks. I think if this is your first time, something like an eight-week timeframe, you know, should be something that you should be targeting.
Another key point here is building in iteration cycles. When you're building and talking about hardware roadmaps, you cannot just plan on your first piece of hardware succeeding. There's probably a much longer term discussion around how to build a hardware schedule, but this is actually well known and we can kind of go through it later. But a key point of this is you're building in multiple points of iteration. EVT, DVT, PVT, they really are three chances to understand problems, address them, and fix them. And then if you can think about logically, you know, pre-EVT as well, it's debatably kind of a fourth, you know, swing at the bat. In terms of software similar and different, the cycles are gonna be a little bit shorter, and that's just due to the natural process of software development. And I think in terms of roadmap, it's really clear and I would highly encourage it visually and also in language to talk about the features or projects that you've taken the time to agree and align on, the requirements and the design because those are the ones that you've got high confidence in delivering because you're just focused on execution. And then, you know, in this example as well shown in gray, these are aspirational. This is what, in this case, my one hypothetical team is going to kind of jump on next and work on next. Again, regular planning sessions to revise the roadmap are super important. I think there's a small topic here around timeboxing activities. There's a little bit of a chicken and egg problem where people often get stuck in saying, "How long does it take to, or how can I, you know, estimate how long the requirements take, how long the design takes?" And I think there's some straightforward timebox style activities here where you really shouldn't be spending more than two weeks on requirements and you really shouldn't be spending more than two weeks on design. If so, there's something bigger at play here and I think you kind of really need to rethink what's going on. It potentially is that you don't understand what you're really trying to build or who the customer is or you're not really equipped, and I think that's oftentimes a different conversation separate from the actual development. And then, I think what's really helpful about a roadmap is it allows people to work backwards, which is probably the most important thing. Whether you're starting with the requirements and working backwards to the design, which is correct and produces the right outputs, or you're looking at a roadmap and working backwards. When you do something like this, you are informing people that, you know, for example, if Feature 2 ships at the end of July and a marketing cycle has to happen one or two months beforehand, then I know when my start date as the Head of Marketing to come in and say, "Look, in June 1st, we really gotta start talking about this," and it allows a lot of people to be much more autonomous. And so again, setting a roadmap and updating the roadmap allows people in the organization to kind of work together and do much kind of more than the sum of their parts.
Nathan, thank you so much. This is a lot to think about around mindset. I think we'll have a future session a bit more in the weeds on product management. I know very few people have worked on as many successful hardware and software projects as you, so we really appreciate that. Some of our Ubiquity CEOs may be reaching out to you in your role as Ubiquity Extended Team Member. Again, Ubiquity Ventures is a pre-seed, seed-stage venture capital firm, investing in entrepreneurs moving software beyond the screen that usually involves a little bit of smart hardware or machine learning. We'd love to hear from you. If you wanna set up a meeting, we're at pitch.ubiquity.vc, and I'm available at sunil@ubiquity.vc. We'd love to hear from you. Thank you again.