Maximizing the Value of Your Features: How to Eliminate Wasted Time

Feature lifecycle

When you dig into a typical lifecycle of a feature, you can identify two main parts. Let’s call the first one “Concept”. Although some of the following phases may be skipped in your particular phase, in general, it looks something like this:

Idea phase

This is the beginning of a long journey. Through continuous analysis of our users’ behavior, and researching the market trends and competitors, we come up with an idea. When this idea is further enriched with data, it is transformed into a hypothesis. Around this hypothesis, we build prototypes.

Design phase

After communicating our findings from the previous step and going through some Q&A, we hand it over to the design team. They are the first to build something tangible out of the initial assumption. They design with the end users in mind, adhering to common UI/UX patterns and avoiding antipatterns. The outcomes of their work are further discussed with the product team and often fine-tuned to their preferences.

Description phase

Now, we have our hypothesis supported by a prototype. Before passing it over to the development team, who will bring it to life, we need to add some details. In this phase, we create an artifact with a refined workflow around our feature. We consider different entry points, alternative scenarios, fallbacks, and edge cases, transforming our concept into a series of easy-to-follow logical steps for later implementation.

Delivery phase

This is where the magic happens, and the previously thought-through artifact becomes real. The development team carefully inspects the description and design, leaves their comments where needed, and shapes the final product with performance, simplicity, and maintainability in focus. A generous amount of time in this phase is also dedicated to quality checks, clarifications on missing information, and unforeseen improvements to the user flow. At the end, we see a beautiful demo and can interact with a feature ourselves.

—

Whoa, what a journey, and that’s only the first part of our thriller. This may not be a complete set of phases, some are going to be dropped or new ones added, but let’s leave that for another movie and follow along to part two.

“Premiere”, is the name for our sequel. While the first part was fairly linear (you can’t begin with the design phase or jump straight to delivery from the idea), the second part usually takes on a Nolan-style narrative. Now, how are we going to execute this?

Pre-release phase

In this phase, we need to settle down on the operational details:

• Release date
• Percentages of users exposed
• Communication strategy
• Support team informing
• Experiment duration
• Control metrics
• Guardrail metrics
• Other contributing factors (season trends, peak events, cross effects from other features etc.)

If we were very careful during the first part, we’d have already planned our rollout or at least prepared some details. That’s an ideal situation.

Post-release phase

Afterwards comes the results collection. If we have multiple data sources around the experiment, those need to be explored and compared. Our analysis outcomes need to be beautifully packed into a meaningful presentation to communicate our success (less often) or share the valuable findings (more often) that would help our organization later on.

Again, part two usually comes in a non-linear fashion. You might talk to the analytics team right after you’ve prepared the hypothesis or communicate with the support team way ahead of the development phase to instruct them on the possible failures. Or you can parallelize tasks: review the functionality and prepare target metrics while “dark launching” as you finalize the experiment plan. The list of potential scenarios goes on and on.

And what if we accidentally missed something on our journey? Of course, that’s something that can only happen in the movies, but still. We can’t release it to our users because:

• This feature adds more infrastructure load than expected; let’s redesign it.
• The prototype looked good in Figma, but not so much when we interacted with it on a test device; let’s update the flow.
• Another team just launched an experiment that would cannibalize our target audience; let’s wait for a while.

All these are time-consuming and prolong our time to market.

This point is really crucial: depending on when your feature is shipped to the users, you could either have a positive-looking ROI or not. Here is a beautiful illustration from “Software Estimation Without Guessing” by George Dinwiddie:

Our break-even point in terms of software development shifts significantly with the delay of releases. Is this detrimental to our results? Yes. Are these wait times and back-and-forth communications justified for postponing releases? For some companies that can afford these operational delays, yes, but for most companies, no. Is this inevitable? No. Here’s what we can do about it.

Overcoming wasted time

In summary, during the first part, we have a lot of sequential steps involving communication among multiple teams. In the second part, we see some parallel tasks that can often become showstoppers and turn the ship around. The ratio between the two is typically 70% for the first part and 30% for the second, so the first part usually takes more time and effort. However, most features get stuck on the post-implementation, the second part. Why? That’s our nature. We are so occupied with nurturing our ideas, seeing their formation and growth, and so unsure we are about sharing them with the public.

To overcome this, we need to have separate strategies for two parts of a typical feature development cycle.

Split and shift the second part

You need to think about the release right after coming up with an idea.

• Talk to the analytics team to challenge your potential experiment.
• Share with fellow colleagues to find out whether they did something similar in the past and how it worked out.
• Review previous experiments.
• Plan the rollout on a timeline and check with other teams.

In the end, you need to leave the minimum amount of time needed for the second part. The stuff that can’t be dealt with at such an early stage.

Eliminate sequences in the first part

It isn’t effective to pass the ball several times with multiple teams. Gather the most experienced and influential people, let them think over the concept together, and produce an artifact. Use asynchronous communication as much as possible. There is no need to create a full-blown technical specification before an engineer can review some wireframes or go through rounds of approvals on a design that is next to impossible to implement in real life.

You should aim to keep the number of concept iterations to a minimum and ideally come up with an easiest, simplest, and fastest way possible to verify your idea.

Conclusion

We love to play the movie director role and delegate all the rest: distribution, marketing, negotiating with movie theaters, issuing posters. This approach leads us to become impatient if a feature takes longer to develop than expected, but we allow ourselves to hold back the feature from users because it isn’t polished enough at the finish line. Whether we accept it or not, this hinders our way to success and significantly limits the number of movies we can shoot during the quarter.

The main point of this article is that, though it may sound trivial, even the simplest change in your product is a pretty expensive endeavor on its own, not to mention the last mile toward the customer. Knowing this, we should stay very attentive to the full feature timeline to extract the maximum possible value and cut down waste, even when it is against our gut feeling.