In part one of this series, we discussed customer-centered data points that can help form product strategy. The next step is to mix in constraints.

The word “constraints” conjures up imagery of being shackled to a ball and chain or being on a leash. In reality, constraints can be a product leader’s best friend, giving focus to what’s truly important and furthering innovation.

‍

Product Vision

Do you have a product vision? Sure, you probably have an idea of what kinds of features you want to include in your app over the long term, but do you have a vision statement written out? What about goals your long-term product is seeking to accomplish?

Have you mapped out the future product? Have you designed the architecture of your app at low fidelity?

These are essential exercises to measure proposed features against. If you’re unsure if a feature fits the vision and goals for your platform (informed by asking your customers great questions, of course!), it can wait. That will give you time to see if the feature resurfaces in any of your research or customer feedback streams, which in turn will help you avoid rabbit trails and edge cases (Think of the 80/20 rule).

Dependencies

When considering future plans for your product, you’ll need to take dependencies into account. Let’s say there’s a feature you know is super important to customers and is the subject of frequent objections from prospects in the sales process. It would make sense to put it first. 

‍

But sometimes from a design or technology perspective, something else needs to be built for the big deal feature to become a reality. It could be a tweak to the back-end data structure, a reworking of the design system, additional setting configuration options, or the introduction of a system-wide component. Think of it this way: What needs to be there for upcoming important features to work?

What’s the Lift?

Ah, the classic “How long will this take to build?” question. 

It’s a complex issue which we won’t dive into deeply in this series, but as a general rule of thumb, the more defined a feature is, the more accurate developers’ estimates will be. In other words, time estimates from developers with only a concept of a feature in hand can be wildly inaccurate due to the lack of detail. On the other hand, clear requirements, along with well-annotated designs, that factor in rainy path scenarios can produce more accurate estimates. 

That said, most features on your roadmap will not yet be fully designed, so less accurate timelines will have to be directional in nature. Even so, an experienced engineering team can do some research into the technology and assess the level of effort in rough terms so you can compare features against each other.

What Will It Break?

When considering new features, it’s vital to understanding the effect of each new feature on the overall experience your product offers. Here are some questions to consider:

• Will the new feature create clutter or confusion when added to what’s already there? If so, what needs to be changed to accommodate it?
• How will the introduction of this new feature impact other features? For example, will new data points need to be displayed on existing dashboards?
• Does the new feature introduce any third-party technology you haven’t used before? If so, does it allow for a cohesive experience across the platform? 
• Can the current technology (i.e. data structure, processes, frameworks) support this new technology?
• Will the new feature fundamentally change how users interact with the platform? What needs to be in place to support that transition?

When looking at what a new feature can break from a UI and interaction design perspective, a design system serves as a vital guide to building a cohesive experience. The consistency a design system introduces is important for users to rapidly learn and adopt a product, so you’ll want to understand any changes a new feature will require to the design system. Will there need to be new components designed? Will existing components used elsewhere on the platform need to be redesigned or adapted?

What about the complexity?

As you can tell, growing a product with additional features also introduces new layers of complexity and cost. Any new feature discussion should be accompanied by centering on what’s absolutely essential for users to accomplish their goals. As an app grows, it also must scale down, some features must be reduced or retired, or the team’s resources may need to grow significantly. 

‍

Think of it in terms of a war. Every feature or area of the platform is like a front. You don’t want to spread your troops thin and accrue the fatigue of fighting a war on multiple fronts. Remember that each feature is not just built and left alone. Each new feature needs to be supported, maintained, learned (by new team members and new users), and tweaked for the duration of its lifecycle. If you try to do all the things, you put your platform and your team in danger of burnout or mediocrity across the board, so it’s just as important to think about what to get rid of in order to maintain sanity and focus.

The Culling Process

When we at Trailmerge design larger feature sets for our clients, we initially design with the ideal in mind. These initial designs are lower fidelity and not as detailed as they’ll end up being when handed off to development. Designing to an ideal state early on allows developers to estimate based on more accurate specifications, helps us to identify dependencies, and gives more concrete sub-features for product teams to be able to break out into separate versions and release cycles.

This process of breaking a large feature or feature set into subunits for incremental development and release should take into consideration what the minimum is to begin showing value to users, affecting revenue (sales, adoption, renewals), and learning from those users. Of course, this subunit versioning and release planning process should take into account all the research and constraints we’ve discussed. Just remember to keep your releases simple and small!

Release Cycles

Every development team works differently, but if you’re running in a truly Agile environment, you’ll have some sort of frequent release cycle. This is a great approach for a number of reasons. It allows for sales and marketing teams to promote something new, and more importantly, it allows for rapid learning on partially developed features, allowing for easy modification of larger feature sets before they’ve been fully built over several months (or years!).

Ultimately, frequent release cycles are a great reminder to strip down features to their essentials, focus on customer feedback, and to not stress about getting it perfect the first time. You are free to deliver something great but small, and continue learning to make a much more customer centered product. 

So hold your prioritization with an open hand, and allow it to be shaped over time by your customers!

‍

Blog photo by Ran Berkovich on Unsplash.