In part one we established that you don’t have a team that has the capabilities to build the product you want without input (and to fill in the blanks, let’s be honest you only specified broad strokes of what it is supposed to do).
And now you’re trying to be optimistic but you really have no idea how long this thing is going to take, and whether the team you have can pull it off. Deep breaths. Time to dig in.
At this point one should note that it’s critical that you establish unshakeable rapport with the team you’re trying to lead. If they don’t trust you enough to be honest, ask the right questions, or the wrong ones (If the latter, then you just received a strong signal your need to clarify or repeat yourself). You’re not going to be able to be effectively lead in the manner described throughout this series.
Now you’re going to take stock of what you’re working with, both of the technological process side and the relative strengths of the team members.
For the purposes of the examples that I’m going to write out in the examples below, I’m going to assume what I’ll call the classical setup. 1 Product Manager, 1 Designer, 1 Engineering Manager (Sometimes referred to as Tech Lead, especially if the developers don’t officially report to this person) 5 Developers (+- 2). Different variations could consist of a Quality individual, though sadly in my experience that’s not fashionable anymore, or a Project Manager, but those last two I’m going to omit since often teams don’t have them.
The first three I refer to as the triangle, because the relative strengths of the three are intertwined. A metaphor that might help explain relates to the term “Minimum Viable Product”, which gets thrown around a lot.
In order to get to that MVP I’d argue that you need a minimum viable talent of that triangle. You can have a stronger contributor in either of those three roles be able to make up in essence for less talented in the other roles, especially in this early phase of definition for the product.
For example, you’ve got an amazing Product Manager, has shipped numerous other complex product, maintained amazing relationships with everyone all over your organization, and my all metrics is one of those 10Xers or equivalent. You can then afford a less skilled Engineering Manager, and / or designer, and vice-versa.
All of this falls apart though, if the triangle can’t work together. If you don’t have that fit, your product will suffer, and may fall apart altogether.
Ok, that’s not the case, you have a competent triangle, they’re defining what your MVP is going to be, how long should that process take? Big question, a lot of other literature is going to say it depends, but I’m going give an actual number, no more than one month.
Why one month you might ask? If you can’t define what you’re building in one month, the actual build will likely take over a year, and when your project has a one-year birthday, it’s a failure. Now it might not be considered a failure to the company, but for the purposes of this blog series it is.
Entire companies rise and fall within a year, and you’ve only built this thing? What is the opportunity cost of whatever else you could’ve been building. Would you have taken on this project knowing it was a larger than one year endeavor?
Now what does the definition phase of a product actually look like? What is the deliverable? The actual thing you’re trying to build will of course vary greatly depending on you business, but the actual output should be roughly the same.
By the end of this phase, you’re trying to gather as much information as you can, and have a strong vision of what to build and why. You should be able to explain to team members and stakeholders, in varying levels of detail, tailored to the audience what your product does. Who is the target audience, what is the TAM (Total Addressable Market) if it’s a business, and what success looks like.
The what might be a feature on a established consumer facing website / app, it might be a new one idea, it might be a pivot, it might be a tool to facilitate some business process. Whatever the case may be, you’re going to need to be able to articulate and defend why this product at the expense of any other potential product.
The why usually takes the form of why some party will benefit once the existence of this software happens. One of my favorite game changers, from years back, in the world of software was Google Maps. It largely ushered in the modern “slippy” map, and also showed the world the power of partial refreshing of the document. Move or zoom the map, more map appeared. Clear benefit for all consumers even in the most raw form. Enter an address and instantly see what’s nearby, zoom out and get a broader viewpoint. Past the MVP it became a platform that expanded into turn by turn directions once Mobile became a thing. Once telemetry was fed back into it, you got live traffic, which changed the world.
In the case above, the benefitted party was, more or less, everyone. Obviously most things will have a narrower scope, so let’s go to the other side of the spectrum. When you build some business that has users, there will inevitably be things you didn’t account for and hopefully you have some way for customers to have their problems fixed. A typical solution for this will be a customer service team. You need to build tools for these team members to self-serve. Otherwise your engineering team will get inundated with common “operational” problems, and won’t be able to build wholistic solutions. So the why you might be building those tools that you just found a need for is to enable your customer service team and free up your engineers.
Output. What are the artifacts created to show you have enough definition to proceed? Some sort of “central document” will exist, potentially a product brief, potentially a wiki document with links to the various engineering tickets your product manager creates, and potentially a design wireframe is about what to expect at this point. I’ve also seen a powerpoint deck created, and that be passed around after a meeting where the output of the definition phase is shared.
One note, you want to make sure that if there are going to be common points consistently arising on the product you’re building, it would make sense to call those out in those output documents, so you don’t have to repeat that conversation.