How To Balance Product Ideas & Project Constraints
The goal of any project is to create an end product that offers something new and innovative. But as any product owner or project manager can attest to, the way we imagine end products needs to be weighed against the constraints of a project.
Managing this balance between great product ideas and project constraints is what allows project teams to deliver the best possible products. Unfortunately, many firms do this very poorly.
This post is going to look at how to strike the right balance between the always-present project constraints (scope, cost, time) and amazing product ideas.
The “Strategy” in Product Strategy
In the product planning, definition, and design phases, the goal is to build a product that provides the best user experience. In planning the product, we are still in a stage that consists of very abstract ideas. Ultimately, the goal is to plan out the perfect product for our purposes. But doing so without regard for project constraints – an error that is all too common – is a recipe for disaster.
In a perfect world, time, cost and scope would be unlimited so that every conceivable feature and functionality could be included. However, this typically isn’t the case, and product strategy teams need to know where they can take the product and have some sort of ideal to strive towards. The product can and should be modelled as closely around that ideal as possible, without compromising project scope, cost, or timeline.
Making The Right Product Decisions
It is often a reality that constraints on a given project mean that certain compromises must be made. However, teams should evaluate thoroughly and compromise as minimally as possible.
This is not a step towards condoning an inferior product to be built, but simply a set of decisions that must be made under circumstances to work towards a realistic and attainable goal of building the best possible product that follows project scope, timeline, and cost. When making product decisions in these scenarios, we must ask ourselves a set of questions before moving forward.
How long will it take to build?
This is the major question – it captures the reason why we are considering changing or relegating a feature. Do we really need to tweak something that will take a few hours of development to build? Are there features that will take potentially weeks to build?
Why are we building it?
What is its role within the context of the entire app? How important of a feature is it? Imagine the app without this particular feature. Determine where the feature stands when evaluating its importance relative to everything we need in the MVP (minimum viable product).
Are there alternatives?
Seek out alternatives to building this feature in the proposed method. Can we find an alternative method that would take less time? How effective is that alternative method at delivering the user experience that we envision?
Example: Building a series of pop-ups to inform the user and prompt for input.
We want to design and build a set of pop-ups that will do anything ranging from telling the user that an inputted password is invalid, to congratulating the user for completing a task within the app. We anticipate that there will be 6 unique pop-up designs necessary to complete this. The total time from design iteration and implementation will take a total of 4 days. The custom pop-up designs are more visually appealing and fit within the overall theme and design of the app. Pop-ups, in some form, will be necessary to give users important feedback when certain actions are performed.
An alternative we can explore is using the platform’s native pop-up elements. While using native pop-ups gives us no control over the design, it is also much simpler to implement. Given we accept that the total time developing and implementing native pop-ups (as there will be no design component), we can estimate that the total time needed is only 1 day. If we can cut the total time used from 4 days to only 1 day, we must also evaluate the figurative cost of this. In terms of functionality and practical value, we believe the two are identical – both use the same copy and thus give the user the same message, and can collect input when necessary. The difference here lies in aesthetics, as the custom pop-ups have the advantage of being designed with the rest of the app in mind. Native elements are designed by the platform creators, and are used in most apps on the market in some form.
In this case, we can opt to use the native elements, because of the amount of time it saves in development and design, and also due to the relatively negligible difference in user experience. While it would be a more complete experience to have the pop-ups custom designed, we do think that native pop-ups do the job well enough. More often than not, a user will read the pop-up and close it within a matter of seconds. However, this does not mean that this particular feature isn’t valuable to have, it simply means that in a time-constrained scenario, it wouldn’t be high priority. It’s perfectly acceptable to relegate it to a list of future updates for an upcoming version as it doesn’t fundamentally affect the user experience.
Making Sure You Ship
The reason why we have to consider compromising on certain features in some cases is because, at the end of the day, the product needs to be shipped. Products need to be delivered within the project’s proposed timeline, and part of what defines a great product is what can be built in a given timeframe. With that in mind, from the product planning phase, it’s crucial that all essential features can be built in time. While we do plan to build the best product we can imagine, we also need to plan our MVP in accordance to any restraints or timelines. If we can plan our ideal product and work towards it while being mindful of constraints, and make logical product decisions, we have the formula for bringing life to our great product ideas.
