The Plumber’s Quadrant — The invisible apps
This is the second article in the ‘Product Portfolio Matrix’ series. The introduction article can be found here.
Currently, we are overwhelmed by a plethora of apps and services that reduces our manual efforts. It could be a taxi app, which saves me from taking out my car from parking, driving in traffic, looking for parking and worry about fuel etc. Or it is a normal get my stuff app, where in addition to the above, I don’t have to walk into a store, try to look for the stuff I need, then move to another store, may be another, scan through items, pick those items and carry them back home.
Now, the quantum of the above work hasn’t diminished. It has changed hands. The work that needs to be done, needs to be done. But by someone else. So, I open the taxi app and whoosh - the chauffeur is here. Or, I order from an e-commerce or e-grocery app and the products I ordered arrive on my doorstep.
What we, as consumers, generally miss from this scene is that a large number of front end products are being developed on what I call the ‘Plumber’s quadrant’. These are the apps / m-sites / web based applications used by all the people involved in executing and delivering the experience behind our fancy one click red carpet apps. As per the product portfolio matrix, these are front end heavy but low end customer visibility products.
With references from three such products which we developed recently
[Partner app for retail, used by retail store managers or area managers of small modern retail companies,
Hyperlocal Store Manager app, used by operation managers to manage grocery pickings and hyperlocal delivery management, and
Hub Manager portal for logistics, used at logistics hubs to manage multiple transits and handshakes],
following are some of the aspects that differentiate these products from the normal customer products:
Top focus is adoption, not conversion
- The most common metrics used in most customer apps are Daily active users / Monthly active users / Conversions in android / Conversions in iOS. In this case, the conversion is not relevant, each user should be using it to ensure success. The product manager needs to track that every user is using the product and check which features are getting traction.
- The partner app required the retail store owner to provide updates on his inventory and price while helping him with all the finance endpoints with the e-grocery company. Interestingly, the inventory and price would help him improve his business and we fed him with all the relevant information. A significant correlation was found between regular price / inventory updates and customer NPS.
- Here is a glimpse of the Partner product — https://www.behance.net/gallery/43211285/PepperTap-Partners
Tip: Go for the right metric. Talk to the end user, talk to many of them, connect with them, understand them, show them marvels before developing and take their inputs. Create simple solutions for their problems and do not reinvent the wheel.
Training is pivotal — inside products and outside
- Imagine a scenario when your delivery guy has to move to a pick up location, get stuff from the store manager, check the count, find customer 1 and customer 2 locations and visit there, provide the stuff to the customer, wait till she checks the items, take back returns, check the final amount to be collected, take part cash part vouchers and repeat the same for second customer and do it all in 60 minutes. It is no rocket science, but the delivery boy is no Sheldon Cooper either.
- The product needs to be so self explanatory and simple at each interaction that one should be able to pass through the whole flow obviously. The product manager needs to create the right training screens / on-boarding flow, training documents / videos in multiple languages to make one understand this. Make it local, make it interesting. Here is an example where we tried to explain how tree structure in a monitoring dashboard works:
Every edge case is a feature
- While developing an app (named diamond) for the store manager, we faced multiple interesting problems inside problems. The major problem statement was — ‘How and when to assign orders to pickers and drivers to improve productivity and removing bottlenecks’.
- When you are solving these problems, first and foremost get the questions right and find as many questions as you can. Operation flows should be known and explained with minute details. In this case, should assignment of Fruits / vegetables and grocery and meat would be done by the same guy, will it be done serially or in parallel. When should the delivery guy be informed. How does the replacement order flow work, how does the cash on delivery submission flow work, how is attendance is taken, can one change if its taken once, how is it linked to order assignment. How much of the flows are automated and when. And 100 more like these.
- Having a state diagram helps immensely too. We realised this during developing our logistics product. ‘Get shit done’ can be taken very crudely sometimes and to ease the workflows on ground, some products can be very lenient. For something like a logistics flow, it is important that all handshakes are sacrosanct, else one would never be confident of where the shipment is and who is responsible for a wrong end state.
Updates should be well transitioned
A lot of effort goes in ensuring 100% adoption and training of these products and this builds up an inertia.
Once on talking about rewriting a massive product to improve operations, I was given just one input — ‘ Please keep the UX same’ , the team can not relearn the new UX.
There is a certain cost of changes. Here are few inputs on how to manage that
- Weigh each major UX change. Most times it should be to enforce an operational habit or culture. For non UX changes, define a metric, force adoption, communicate and change accordingly.
- Gamify adoption, wherever possible
- Take a tough call if it has to be taken. Convince operations, team on ground, team leads whoever. What needs to be done, needs to be done
- Don’t be committed to Visual UX that appeals to you. Your design sense might not be congruent to your user’s design sense. Ask 10 of the users instead
- Be local, try to use local languages, use simple words. In case your designer is building these products, ask her to meet and talk to some of these guys
- Make incremental product transitions. These products will teach the PM, the real MVP structure. Stay minimal, stay viable but stay growing. Check how the current features add up to plateau this product in 6–9 months
Summarising — Listen to the problems and not the solutions. Just stop when someone gives you a solution, ask the problem. They will hate you first, but they will love you later. Solve for them, solve with them. That’s an investment in Plumber’s quadrant product.
