Dear Product Manager, it doesn't end when you launch

Ope Adeoye 4 minute read

I have been lucky to get a chance to be at the frontline of a few product launches. In all of them, for the products (or releases) that did well, I noticed a pattern. 

In the weeks and months of engineering & design, while the teams are toiling away banging out code, layouts, architecture, refining marketing plan and dotting the i's on the pricing, things could get very very intense. And fun. On the day QA gives the final "go" on the last build and we push to production, there's usually this huge euphoric release that gets everyone celebrating and slapping one another on the back. We even have a sort of tradition, the product manager or any motivated-enough member of the team buys pizza or buckets of ice cream or whatever catches her fancy that day and circulates. If there's a launch event or a marketing campaign that breaks immediately, the feeling is even heightened some more. 

From what I have seen, for the products I have been a part of that did well, it's what we do AFTER these events that make the difference. 

No matter how hard we worked, how well we planned, how nicely we convinced the first set of customers, once we ship and the feedback starts coming in, all sorts of scenarios we left out start popping up. The technical debt we left out starts to bite our asses. 

I have noticed that keeping our heads down and digging in, at times for up to 2 years, taking feedback, iterating quickly, not stopping, is what usually determines the success of the product. 

For us, it usually starts from putting together a pilot report that contains data & behaviour analysis of the early users, how the systems held out and a survey of customers. Then we have to measure the impact of the marketing efforts, what's working and what's not. Often, because most of the Quickteller related product launches have a bank (or other external party) component, we pay them visits to get their views and "solicit" for improvements where there is need on their parts. 

All the above is the boring, hard part of the work. Its not as sexy as building and shipping the v.1 code base. Weekly reviews of this phase are more about customer support or "something not working", though once in a while, we get the motivating cool new feature addition. 

The way we stay on course and commit to handling this part (after the launch) is what has separated the successful products we shipped from the ones that didn't do so well. 

So why not just ship that v.1 already knowing that the real work of products starts after the launch. 

Don't sit on it, ship.