One of the reality of a product development is the fact that the shift between project and product is something that happens so frequently. I always imagine product development goes into 2 big activities that happens in a loop: Discover and Deliver. First part plays a big role in determining what to build and more importantly why. You may say it’s the research and prototyping phase of product development. The second part is the execution part, how the team build the product and how it reaches the customers.

Of course, because this is a loop, then the movement has to swing from one activity to another at some point. Once part of a product has been formalised and agreed, a team can go from Discover mode to Deliver mode. After what’s ended up completed during development reached customers, the product team now has something new to learn that will influence the next Discover mode.

The first time I learned about product management, one thing that got mentioned quite often was how different it is from project management. However, after years of practicing product management, I realized that though these are 2 different beasts, a product manager knows exactly when he/she should go into project management mode, especially in during Deliver mode. This is the moment where a timeline (however variable it is) is already agreed and the next Discover step will be dependent on this phase’s success. Of course things won’t always be smooth, some adjustments would be made here and there to react to various uncertainties, but the goal remains the same: how can we complete a deliverable within specific time while utilizing finite resources.

Complexity in Delivering

Based on the explanations above, there are 2 things that are vital to the overall product development process, yet they are susceptible to vague definitions that will only cause harm if handled poorly, especially during Deliver mode:

• Description on what to deliver
• Uncertainties during deliver

The whole agile movement provides us with method and foundation on how to properly manage those 2 factors. But in reality, there are nuances to these and how an organization proceed, really depends on the context of the actual development.

Organizations that develop product purely internally will need to align the product development practice with the bigger organization goal. This is where goal setting framework such as OKR comes into play. Aligning OKR with Product Roadmap as well as the development activity will ensure that the product development loop runs in a way that gives value to stakeholder and clarity for product team. There’s a clear description on what to deliver, along with the reason that goes hand in hand with what the organization is aiming for, while also infusing learning from the product delivery.

Granted this is a rather simplification of what actually happens. But based on personal experience, this is a framework that puts Discover and Deliver mode in harmony with the actual organization goal. Yes, it will put difficult conversations between stakeholders, but those are important interactions that should happen inside a product driven company. The flexibility of having an internal team that does product delivery within the communication range of stakeholders can bring clarity to both parties on a day-to-day operation.

Talking to External Parties

Now what happens if we’re to replicate this setup in the context of executing product delivery through third party vendor? How many should we adapt? The answer is, not much. However, a major shift needs to happen in what we hand over to the client and this requires a big transformation in mindset on how we treat project.

A common transaction that happens when performing product development through third party is a client gives a set of requirement that needs to be delivered. The vendor is then given a specific date and cost to transform the requirements into working software. On paper this works, but in my (and probably yours as well) experience, this is rarely the case. It’s not easy to correctly assume in the beginning that a set of features can be developed within specific time and resource. Remember, uncertainty is a certainty when it comes to developing software. Moreover, assuming that this will bring positive business impact ended up being just that, assumption. Ultimately, we’re working with vendors that wound up being feature factory and it’ll be hard to pinpoint the actual value that the whole project produces.

The solution according to the framework I described in previous section, is not by evaluating vendors through sets of delivered requirements, but rather through a measurable outcome, similar to what we have in OKR. Resource wise, a client can hire a team (or vendor), treat them as internal team and pay on monthly man hours basis. How the hired hands are utilized is then dependent on how they plan the deliverable in order to fulfill the targeted outcome. This will give the vendor a degree of freedom to deliver, still according to constrained time and budget, but the deliverable should be well aligned with the business need of the organization.

However, as I mentioned above, this requires huge shift in the mindset of a client. A project officer needs to act more product manager, as he/she has to be able to properly think what metric to measure that will bring positive outcome to the organization, before handing it off to vendor to deliver. The delivery result should then be evaluated on regular basis to see how far is it to reach the outcome or even to think is the number still matters.

In the end, what the business needs is not features, but outcomes. By thinking more outcome oriented and design project around such mindset, we are ensuring that the product gives positive impact in responsible manner.