Product Principles: Always Move Forward
Editor’s note: This is the sixth post in a seven-part series from Levvel’s Product Innovation team that details the critical product principles the team lives by. Also see parts one, two, three, four, and five.
Too often, we hear people talking about software projects in terms of a linear construction process—moving through phases like strategy, design, and development towards a final release date. Unfortunately, that ignores the long term reality of what it means to develop and manage a software product. If you take the long view, you’ll see that product development actually follows a cyclical pattern of insight generation, design, development, and feedback.
Software creation doesn’t end after the launch any more than it does after a design session. A successful product has to be perpetually designed, implemented, measured, re-imagined, and re-implemented if it is to be successful and remain that way. The key to success for a product owner is to set up that cycle and repeat it quickly and efficiently.
On Levvel’s Product Innovation team, we’ve learned that one of the most valuable things we can do for a client is to increase their awareness of this cycle to help them move forward through each step with increasing velocity. We do this by helping clients succeed in whichever stage they’re in while simultaneously guiding them toward the next step in the cycle.
Always Move Forward
As consultants, we almost always get brought into a project at some point in the middle of the process. When this happens, it’s natural to want to take the client back and revisit some past work we think the client’s team could have done better. However, we’d be doing them a disservice if we didn’t instead help them move forward.
For example, clients often come to us during the build phase of a project. They have designs and are looking for an estimate for implementation. We would have loved to lay the strategy and UX groundwork of the application, but trying to push a client backwards and convincing them that we could do a better job isn’t an effective strategy. The client stands to gain a lot more by building and measuring an imperfectly designed application than by going back and spending more time redesigning it.
Instead of going backwards, we help clients move forward. We help them succeed in their current phase (build) by prioritizing a core feature set that gets them a product in hand as efficiently as possible. That product doesn’t have to be released to their customers. It might just be a prototype for company stakeholders or a beta group.
More importantly, we set clients up for the next phase (measure) by immediately defining success criteria. What do we expect to happen once this application is built? What does success look like? How do we measure that success? What’s our next step if we aren’t successful?
Asking these questions changes the way clients think about their product. The iterative mindset immediately pays dividends by speeding up implementation. If the client knows who will be using the app and how it will be measured, they can make feature decisions much more quickly. It improves team chemistry by bypassing long arguments about whether someone’s favorite feature will make it into MVP. Not only do we have objective success criteria to guide discussions, but feature arguments framed in terms of priorities (e.g. “build this feature now or later”) are much less contentious than those framed by absolutes (e.g. “build this feature or don’t build it”).
Once the client reaches the build milestone, they can objectively measure how well the application is performing. We use this information to learn more about our users—this is the next phase of product development. Our new learnings can be rolled into an updated product strategy, leading to the design of new features. This gets us all the way back to the design phase, but we got there by moving forward instead of backwards.
By moving forward, we end up where we wanted to start, but with a stronger team and product. We have real customer feedback instead of stakeholder conjecture. We have alignment around goals. Most importantly, we have a project team with stronger relationships and more experience moving through the product lifecycle.
A software product is never actually “complete”—it is a living thing that continues to grow, learn, and adapt to a changing landscape well after its initial release. The most valuable thing we can do as consultants is to help clients understand and leverage this cycle. Rather than telling them about it in a sales meeting, we show them by always moving forward.