Going Live with a B2B / B2B2C Product

My past few months at TeamApt has been quite an adventure. It has been challenging and rewarding as well. I have been largely tasked with building a digital banking solution that the customers are supposed to love. Recently, we have been implementing a product for some customers and I must say, we learnt a lot of lessons “going live”. Here are a few of the lessons learnt.

1. Ship Early

Working with smart guys is a great thing. Good developers always want to ship out elegant code with the optimum user experience. They technical guys want to be able to brag about the code quality, transitions and all that stuff. But truth is time is running out. However, the most important thing to the customer is “Does the product do it’s job well?”. The customer’s pain is not code quality, fancy UI screens and UX. These in themselves are a means to ensure product quality but the users don’t care what frameworks, tools or algorithms are used.

Too many times techies spend too much time changing trivia things along the way and wasting so much time in the process. Don’t fall into this trap. Keep your eyes fixed on the goal. Of course, there may be need to make some changes due to real technology limitations or customer requirements but don’t let that smart devs or UX guys derail you. Ship early!!!

In a bid to ensure that the product is perfect, in other words, complete with all features, there is a risk of shipping late. My take is to ship something that works well first largely to give comfort to the customers and gather quick feedback. Most times, customers don’t provide full details on what exactly the requirements are until they interact with the working product.

2. Use Your Own Product

An easy way to test and improve your product is to be the customer yourself. You would gain valuable insights and wear the customer’s shoes when you use your own product. One would be able to work very quickly with facts not just assumption. You are generating your own feedback. In our case, we signed up as a customer on the corporate digital banking module and we used our own product. Our admin person who is main user kept providing feedback that helped shape what our updates contained, what bugs were discovered and what features seemed incomplete. It was rewarding, I couldn’t have imagined what the customer would have felt despite our countless engagements during demo sessions.

3. Things would Go Wrong

Going live with a B2B solution in the customer environment would always come with its quirks. This is largely because the test environment is usually never an exact mirror of the live environment. Though the differences might be subtle, it may sometimes lead to re-work on the code base or DB queries and all that. For this reason, I would advise that you ship early enough to get familiar with reality…Ship Early!!!

4. Always Ask Why

As you roll out and customers begin to use the solution, there would be feedback. There would be a request for more features or tweaks to existing features. However, a mistake often made by junior product managers is taking customer request “as is” and jumping straight into implementation without understanding the reason for the request. As a result, some enterprise products contain several features that do the same thing and this can be a demotivation to the development team when one programmer finds out that another colleague is building what already exists or is coding what could have been achieved via a configuration.

5. Monitor Performance from Day One

As you roll out your product, define your KPIs well ahead and start tracking as early as possible. It would be nice to know, what features customers use the most, how they typically use the app, how much revenue is generated, how many customers use the product, how often is it used, etc. This would let you know if you are course for failure or success as well as the need to make adjustments.

6. Fix Only Showstoppers First

As you roll out your product, there would be need to make some tweaks, bug fixes or add new features. However, not all of these are of equal importance. Fix high priority issues first. It might be tempting to fix all the issues at once, but don’t fall into that trap. Rather, classify the each issue as high, medium or low and fix them in that order.

---

In Conclusion

Going live is an interesting phase of product development. Seeing your ideas come alive in the hands of a customer is rewarding in itself. But it is also a time to put in extra work hours. It’s like giving birth to a baby. This is a crucial point….. so Let’s Go Live!!!