As I reflect on my years of product management work—and flip through all those books on building successful products—I can’t help but feel like a few pages got left out. Sure, the books are packed with tools and frameworks, but some of the best lessons? They come from real-world experience and the occasional curveball life throws your way. Unfortunately, those don’t always make the final edit. So, in this blog, I’m going to fill in a few of those gaps by sharing three key mantras that you won’t find in the typical "how-to" guides. No need to keep you in suspense—let’s dive right in! Here are the three mantras: 1) Design for first sales contact not last 2) Design for renewals new logos and finally 3) Design for experience not functionality. Before we delve into their meaning, let’s first clarify what they are: these are "mantras" for product "design". I’ve deliberately chosen the term "design" instead of development or build to emphasize that these principles are most effective when applied during the design phase of your product. If you’re already past that stage, these mantras might encourage a return to the drawing board—something that could very well be worthwhile. It's also important to note that we are not discussing product strategy or go-to-market plans here. This is solely about the design process: once you've identified the market need, completed the business requirements, and are ready to begin creating the actual product. The second word I’d like to highlight is "mantra." While the term carries deep spiritual significance—far beyond the scope of this blog—an oversimplified yet apt interpretation would be "a tool for the mind." And this, I believe, perfectly captures what I aim to convey. These three principles are, in essence, tools for the mind. They are concepts to keep at the forefront of your thoughts, to focus on entirely, and to continually measure against as you design your product. Now, the mantras themselves: 1) Design for the First Sales Contact, Not the Last Many products are designed in a vacuum, assuming that a traditional sales cycle will naturally lead to revenue generation. However, today’s buyers of software products and services are bombarded with options, and their time to engage with each one is limited. While a good advertisement may help, the industry's direction is shifting towards Product-Led Growth (PLG). This approach focuses on making the sale at the first  contact, rather than waiting for a lengthy sales cycle to conclude with a signed purchase order. PLG strategies today generally fall into two categories: a) Simplify your product or break it into SKUs:  This allows the smallest SKU to be purchased with a simple card swipe. While this seems straightforward, it often isn't enough. Customers frequently have little motivation to swipe their card for your product versus the many others available. They may have seen your product’s features, but without deeper engagement, they haven’t invested enough to commit to a purchase. b) Provide a sandbox for customer trials:  This approach lets users play around with a limited version of the product. While some customers, especially developers, might enjoy this, you often end up attracting users who aren't the ultimate decision-makers. In these cases, the true essence of PLG—engaging the buyer—is lost. So, how do you apply this mantra effectively? Start by considering the buyer persona and the closest persona who might want to explore your product. Then, design the PLG experience for that  persona. You don’t need to offer a complete implementation right away, but provide enough for them to feel the following: a) Simplicity with a promise of quantified benefits:  The experience should demonstrate that your product is easy to use, and the potential benefits are not just quantifiable  but are already being quantified . b) Partial implementation during the trial:  While the user is exploring your product, they should feel like they’ve already made progress—half of the work is done. The benefits have been quantified, and it’s now just a matter of completing the transaction to fully realize those benefits. c) A safety net for discontinuation with benefits that they can keep:  Make it clear that there’s an easy way out if they decide not to continue. This reassurance reduces risk and encourages them to take the initial plunge. But leave them with some realized or soon realizable benefits that keep they think about and want your product. In my view, this is what it means to design for the first  sales contact, not the last. By focusing on creating an experience that engages the buyer from the outset, you are setting the stage for a smoother, faster, and more compelling path to purchase. 2) Design for Renewals, Not Just New Logos Sure, we all love new logos—they bring fresh revenue and open doors for potential expansion. But that’s a sales  objective, not a product one. When it comes to product design, the mantra should be to focus on renewals  rather than chasing new logos even while building a new product or feature. Here's why: If you design primarily for new customers, the temptation is to pack the product with flashy new features, hoping to impress. This can often result in a bloated product that’s difficult to understand, challenging to implement, and a headache to maintain. While it might catch attention initially, the long-term customer experience often suffers. On the other hand, designing with renewals in mind helps you create a product that’s simple, intuitive, and valuable over the long haul. Here’s how this mindset can work: a) Keep it simple:  Prioritize ease of use over a laundry list of features. It’s tempting to throw in every bell and whistle, but customers appreciate products that are straightforward and solve their problems without overwhelming complexity. b) Short implementation cycles:  Focus on reducing implementation time by automating as much as possible behind the scenes. A smooth, quick setup experience means less frustration for the customer, leading to greater satisfaction from the outset. c) Ongoing value communication:  Continuously showcase the value your product delivers—not just to the users, but also to the decision-makers responsible for renewals. They need to see clear, ongoing benefits from the product to justify sticking with it year after year. d) Make your product "sticky":  A well-designed, easy-to-use product creates loyalty. Customers don’t want to switch—even if there are slightly cheaper options—if your product is serving its purpose well and isn't causing headaches during implementation or maintenance. By designing for renewals, you ensure your product remains loved and indispensable. New logos are great and guaranteed with such design, but when customers feel that your product continually provides value with minimal friction, renewal becomes almost a guarantee. This is how you build lasting relationships with clients and create a product that isn’t just sold once—it’s sold over and over again through customer loyalty. Your existing customers will spread word of mouth that will help you get your new logos. 3) Design for Experience, Not Just Functionality This concept could easily stand on its own blog, but let's break it down simply here. Your users aren’t just workers—they’re people with emotions, goals, and lives outside of their day jobs. They want to feel good about their work, and then go home to their family and friends with a sense of accomplishment. You can design a product that merely gets the job done, or you can create something that makes the experience enjoyable. Here’s how you can approach this: a) Think beyond function:  It’s not enough for your product to just work —it needs to be a joy to use. Whether it’s a simple form or a complex workflow, your design should enhance the user’s experience. Focus on elements like layout, colors, and ease of interaction. Even the most mundane tasks can be improved with thoughtful design. b) Empower the user:  Help your users feel a sense of achievement in their day-to-day tasks. For example, if they’re filling out forms, design it in a way that makes them feel productive—whether it's by tracking progress, suggesting improvements they can share with management, or simply making the process quicker and easier. Every small win counts toward their sense of accomplishment. c) Enable them to shine:  Design your product in a way that allows users to showcase their work. Make it easy for them to demonstrate their efficiency to their boss—whether by reporting how many forms were completed or by suggesting ways to streamline processes. This turns routine tasks into opportunities for the user to stand out. d) Create a pleasant, repeatable experience:  Users should want  to engage with your product day after day. Consider what makes the experience enjoyable in the moment—whether that’s a clean design, smooth functionality, or small rewards for completing tasks. At the same time, think about how you can build a long-term relationship with the user by making the product something they look forward to using, rather than dreading. By designing for experience, not just functionality, you elevate your product from being just another tool to something users genuinely enjoy using. This thought process will fundamentally change not only how your product looks, but how it feels  to your users—ultimately creating a more loyal and satisfied user base. A great product doesn’t just solve a problem; it empowers and elevates the user in the process. Conclusion: At the end of the day, your goal is to create a product that stands out in the fiercely competitive market, one that not only gets adopted but stays indispensable. A product that sticks, delights, and turns users into champions who advocate for both initial purchase and renewal. These principles aren't quick fixes—they require intention and effort—but they are powerful mantras , tools for the mind, that will set your product on the path to lasting commercial success. Embrace them, and you’ll design something that doesn’t just sell—it thrives.

"So glad we met, Maya," Jay said as he gently pulled the chair for her. She smiled as he took the other chair at the table. Light music playing in the background, the setting was perfect for a first-time date that could turn into lifelong companionship. Both in their middle ages, they were attendees at the "Fun with data" club. Their interest in data turned into mutual admiration, and mutual admiration evolved into attraction. Jay was impressed with Maya's sharp mind while Maya admired Jay for his ability to talk from experience.
As wine was being served with hors-d'œuvre, both shared topics of interest, made fun of a small canapé served on large plate with a dash of red sauce garnish. Smiles and laughter filled the evening. It felt to both like this was heading somewhere. So of course, the conversation got a little more personal. Maya was curious about where Jay was from. "Oh, I am from here, California. My parents moved to USA a few decades ago. And you?" "Zeta, I am from Zeta," Jay could not hold his laughter at what seemed to be Maya's sense of humor.
"No, seriously, I am from planet Zeta," Maya assured him, "Yes we are aliens, but please do not stereotype us as beings with funny eyes and elliptical heads. We are a race from another planet."
Silence. Silence was what Jay was left with. Not sure how to respond, he looked for the menu card and changed the conversation towards choices for the main course. There was a nervous storm of thoughts in his mind. Maya seemed pretty calm.
Breaking the silence Maya said, "Hey.. we are very much like you. You can meet people from other races, cultures, countries.. I am from a different race, culture, country.. just from another planet." Jay had to go along. Both knew that there was a certain attraction. They needed to make it work. Both being very analytical, they decided that the best way ahead was to get to know each other better. Maya had been in USA and in this world for many years. So she knew humans reasonably well. Jay needed to get himself up to speed. Maya had to take the lead and explain her race.
How does one start to explain their race? Maya wondered for a while, and then started with what she was good at - data, numbers. After indulging briefly with the age of Zeta as a planet, population numbers, etc., she realized that Jay was still feeling alien. She had to say something that sounded similar. Something that brought them together. Made them feel like they are not different. But what she said raised a Tsunami. A Tsunami that threatened the existence of their togetherness. "We have a similar age span as yours," said Maya. Till then it felt all right, but the next sentence raised the Tsunami "We are from opposite worlds. We grow younger and more efficient every year. We are born with faded intelligence, somewhat like an elderly person with fading memory and ability to make decisions, and then we get sharper and more efficient until our very last years of life. And then like all everybody else, we cease to exist"
She ended surely on a grim note, but death always is so. More striking was the fact that Maya was living a life that was the opposite of Jay. Human intelligence gets sharper in the early years and then diminishes in the later stages. Maya on the other hand would stay sharp and get more efficient by the day. Jay said to Maya in a very soft, careful and sad tone, "So if we live our lives together, you will get smarter and efficient, while I will fall behind. I will continue to be a burden on you. At some point you might be better off depending on yourself than me. In our world, I might not even be needed. I will be a living burden trying to catch up with you and failing every time. You will keep getting smarter, and I will depend more and more on you. That depending on you and my aging will make me weaker and more useless. Do we really have a life together?"
The soft music continued playing in the background. Only now the setting felt like a first date that had ended the companionship even before it took firm roots.
So they were at crossroads here. What should Jay and Maya do? Maya had no control over stopping herself from becoming more efficient by the day. Jay could try to catch up with Maya but it was not humanly possible. There was a magic potion that Jay could use to slow Maya down, but should he? Or should he just exhaust himself trying to catch up with Maya? Or should they decide to live together and live with the consequences? Or is it best that they go back to their own worlds and do not let their worlds intersect?
Aren't we at the same crossroads? AI is getting more efficient by the day, and humans are losing the ability to make decisions. Humans can try to catch up, but can they really? They can slow down AI, but should they? Should we live with the consequences of letting AI grow? Or should we part ways with AI, and go back to the pre AI world?
The soft music continues. #artificialintelligence #fiction #machinelearning #productmanagement

"This feels good. I'm loving this. I Love everyone and everything in this dream." Just as Jay was having his longest dream so far, he was interrupted by an uneasy feeling. There seemed to be something wrong. He slept for 14 hours. Usually Jay enjoys his dreams, but today was different. He realized something was not right. Unable to put his finger on it, Jay ruminated. Alas he figured it out. He knew exactly what went wrong. The problem with the dream was.... Let's Rewind five years. Jay joined a company as a sales person. A freshly minted business graduate, armed with all the cutting edge tools he picked up at his business school. Molded by mentors at work, Jay quickly mastered sales. He could always place his product, speak eloquently, understand the buyer's sentiment, and tailor killer sales pitches. He had been flown to resorts all over the world as the best salesman of the quarter. He was quick on his feet, figuratively in terms of addressing his buyer's concerns, and literally in terms of trotting the globe closing deals. He had one confusing concern of his own though, leaving him restless. He wished for a potion that could help him sleep to take his mind off of it. The prestigious resort getaways were days and nights of work served with a shot of sea, the sun and golden sands. Hardly any sleep and never any dreams. Three years later, Jay's company introduced the sales chatbot - a virtual sales agent that would learn from Jay and his colleagues' emails and recordings of online meetings with customers. The sales bot would then conduct inside sales, answer basic questions and address buyer concerns. It lightened Jay’s workload. With the chatbot at his side, taking care of basic processes, Jay was able to sleep for longer hours. But alas! still no dreams. It was around this time that Jay met a ‘dream merchant’" who gave him a magic potion. "Be careful with this," the dream merchant warned , "This will make you sleep longer and give you blissful dreams that stick with you beyond fleeting impressions. Do not overdo it." Jay was stoked. He knew he had only six hours of sleep. He did not have the luxury to overdose himself. So he took the potion and it was magical! He had a wonderful dream that night. He dreamt of lovely landscapes, glistening turquoise blue oceans, wavy green fields, dense foliage, and many happy folks singing while they work. He saw himself as a happy farmer sharing bread with others, a nice little family, ample time to appreciate life's beauty- a resplendent life. Then the phone alarm went off, waking him up. This continued for the next three years. The sales bot got better at its work, slowly taking on more responsibilities. Now Jay had increasingly more time at home. He gradually increased the dosage and dreamt for longer hours. Six hours of sleep became ten, then twelve and more. He would quickly wrap up his part of the work, while the sales bot would take on the rest. Today: a rude awakening. Jay felt fortunate and lucky with his dreams. He loved his life as a farmer in a beautiful land - land of abundance. He had everything and anything that one would dream about. However, today's dream left him with a void. It felt different. Something was amiss. He sees the all familiar skies and blissful glades, the family guffaws, but where am I? Why don't they see or hear me? His apprehension mounting. He just vanished. He is no longer in it! His euphoric dream had come to an abrupt end. His role in his dream has faded like moonlight into the darkness with every passing day. Jay was deeply upset. He quickly got up, rather he tried. His legs felt heavy, these long sleeping hours had made him less active in real life. After all, he was leading a smaller real life compared to his larger dream life. He felt hopeless. He was neither a part of his own dream nor was he feeling accomplished as he once did. It was growing difficult to stay awake and engage in his real life. He dragged himself to work. His day seemed ridden with disheartening news. He lost his job. His customers had built a buyer bot. The sales and buyer bots were more than capable of conducting business. They were almost sentient. Humans were incapable of participating in such transactions. He had no role at work. His position was eliminated.. from his job, his waking life, and from his dreams! Is this the reality of today's world? With generative AI readily available, general AI not too far and robotics in advanced stages, did we create a dream world that is so efficient and sentient that we do not have a place in it? And will that dream make us incapable of participating in real life? Are we losing to machines and artificial intelligence in terms of skills, creativity and productivity? Do we want to partake all of that magic potion called AI? Or can we be more responsible about it? Time to govern AI, making its usage socially responsible perhaps? After all, the dream merchant did advise Jay, "Do not overdo it!". #artificialintelligence #machinelearning #AI #practicalai

"Doctor says I have a few months left," said Som as he patted the honing machine, "it's time to leave the world. But I had to come to see you. You have been my partner for years. I kept talking to you as I worked on you making those precision barrels for high quality super precise ammunition guns. And you gave me the least trouble. We worked well. Wish you could talk." Som wiped off a tear from his eye knowing he was nearing his end. He was seventy and had a cancer diagnosis. In all his young years, he had worked with the ammunition gun factory. And all that time with this machine that he cared for most. He prayed before starting work every shift. He knew that he spent more time with this machine than anybody else - friends, family, tv. "I went inquiring about you to the factory floor, where I saw you last before taking voluntary retirement a few years before retirement was due," Som continued talking to the machine as he always had, "and they told me you had aged, and have been moved to this factory scrapyard. They seem to have taken some parts off you already. OK buddy, this is it. My last goodbye to you. I do leave you with a heavy heart. Not sure how you felt working together. It’s my end, and looks like yours too." Som started to get up from his chair, frail and holding his walking stick. One year later, Som is no more. In a quiet corner in the garden outside the factory, lies a small memorial. Made with parts from the aged machine. And on it are the words "In loving memory of Som, our senior foreman who showed us path to new opportunities, and MoH, his dear machine.” It was Som's wish to have his memorial made with what remained of the aging machine, for that night - one year back, he met with the machine and had a chat - a chat that made some eyes wet and some minds think. So what happened in that final goodbye? Som grabbed his walking stick, and began to stand up. The cancer in his stomach had spread. It was painful. But the tear in his eyes was from the bond this man shared with this machine. "Wait. Sit," he thought he heard the machine speak, "It is not over yet- this meeting. Don't you want to know what I have been through? I loved you all these years, you treated me like family. But I do have a heavy heart. It was OK for you. When you could take it no more, you took retirement voluntarily. What about me? They continued using me." "Heavy heart" said Som feigning ignorance. "You know it Som. You told me before you left. You were tired of making those gun barrels that killed. We have many deaths to our name. You could not take it and you retired. I had no choice. I kept improving the quality of things that kill." "Kept improving, how?" "The world has changed Som. They attached some sensors on me, collected tons of data. They got some smart folks who kept doing some wizardry on their computers. All I know is that my settings kept improving and I got better and better at my job - better and better at killing people with the guns they made from me. But hey they were able to make me run better than you could," the machine teased Som. "Yeah right," Som felt challenged, "Did they really?" Som knew he was the best. How could anybody make this machine work better than him? "Yes they could. They made me better," it seemed like the machine was reading Som's mind, "They learnt from me, from my data. They said I was learning - machine learning. What idiots. They were learning, not me. I was always good." Humor laced with sarcasm. "You should be happy then. You don't have to listen to my complaints and a computer can set you up for success," Som was equally sarcastic. "Relax Som. just pulling your fragile leg," the aging machine comforted, "but you know what. I got tired. These computer scientists are very smart. They capture machine learning, but what about human learning? No sensors for you humans uh? or nothing to learn from you humans?. You were pretty bright. They should have put sensors on you too,” the machine seemed to be in its element. "It is all over my friend," Som responded, "our days are over. Just wishing for a peaceful death. I took retirement, practiced my religion, hopefully washed away my sins of making these killing machines." "Good for you Som. Not for me. I may be aging and almost scrapped. But I will continue making these machines that kill. Bad karma will continue." "Wait, what?" Som was curious. "It's true - what I said," there was sorrow in the machine's voice, "I will be dead and gone. But will continue to kill. When they cremate you, your brain will die Som. But mine, no such luck. They have captured my life's worth of experience. They will use it in new machines to make them smarter by the day, and they call it artificial intelligence. Can you believe it? My intelligence is called artificial intelligence. I will continue killing through many other machines. This is what I leave in heritage to the next generation. Not property, not wealth but intelligence to kill" "I feel sad for you my friend," Som comforted the machine, "After I retired, my daughter build machines for better uses with a little help from me. That is my emancipation from bad karma - at-least I tell myself that.” "Ah!" this time the machine did not sound sarcastic. Rather relieved. Som looked intently as he felt the machine had something to say, something that sounded like it's nirvana. "Do the same with my learning Som. My learning is not about making better gun barrels, but about honing tubes more precisely. Surely there must be better places to use my brain. The doctors who tried to work on your cancer. Ask them. They might get better surgery machines. Do something Som. Get me out of this vicious cycle of creating more and more death even after I die. Give me some good karma Som, some good karma... please," the machine pleaded in a fading voice. Som bent a bit to kiss the machine his final goodbye. With a heavy heart, he grabbed his stick and began to rise. There was absolute silence in the scrap yard. Just a frail man walking away from his beloved aging machine. The silence seemed to be his final goodbye. A silence that had the determination of doing something good with machine learning. Som championed use of data and machine learning across industry to transfer intelligence. His factory owner was eager to experiment. And that earned him new orders in health care and other industries. For the business, Som had opened more doors. But for Som, it was his final farewell from a dying man to an aging machine - A machine with a heart. Som named his dying friend MoH - "Made of Heart.” Som is long gone and so is MoH. There stands a joint memorial in the corner of a small factory yard - a memorial of two friends who taught the world a lesson to find good in every artificial learning exercise - even in an industry that kills. #artificialintelligence #machinelearning

Services Management has come a long way. From ITIL (ITSM) to Customer and HR Services workflows, leading vendors have used the benefit of data driven technologies to make services and related decisions more effective. It is these vendors that I wish to address in this post. They have done an incredible job of living up to and even exceeding expectations, in some cases even defining the market. Now it is time to up the game in a way that the market gets what it needs, and your license revenue soars. Let me start with a general concept before getting specific on other topics. It's time to re-orient services towards those served rather than functional domains. It is time to have Employee Services Management, Consumer (B2C) service management, Enterprise (B2B) customer service management and Vendor (tier 1, beyond tier 1) services management. Of course, there is more that need to be served, and more drill down within employee types (remote, hybrid, on site, SREs, etc.); but the purpose of this paragraph is only to highlight a unique perspective to building workflows that could introduce specificity, and in turn have a better win-win (license revenue for vendors, value for customers). Hint: As an example, in this era of "remote and hybrid work", do you provide anything in your workflows that provide confidence to both employee and employer that use of employee's home resources for work is safe? This sits at the intersection of IT and HR Services Management. Hence the need to serve by personas and not functions. Many of today's services management products focus on "Mean Time to Resolve" (MTTR) or "First Call Resolution" (FCR) as their go to metric. This needs to be reexamined. For starters, analyze your own data and find the distribution of MTTR. You will see that some cases are solved over the phone/ chat / self-help, some take a couple of days, some get into investigation mode (sometimes from weeks to months) and others linger for ever. For the ones resolved over phone or some form of self-help, it will make sense to focus more on experience rather than MTTR. For the rest, re-engineering the resolution process is equally important. And focusing on resolution might help with addressing some of these issues over phone/ self-service rather than lengthy investigation, saving cost and improving quality of service. This is more surgical than just identifying intents that need more resolution time. This is about helping your customer design resolution paths keeping in mind intent, risk of faster resolution and reward in terms of customer lifetime value and NPS scores. Hence my use of the rod "re-engineering". And both (improving experience and resolution paths) can get help from better workflows and data / AI support. There is more to discuss on improvements to workflows, but to keep this blog concise, let me move to the next topic. I will conclude this paragraph by mentioning that Services Management Software can charge a premium for helping customers improve their experience and resolution, by helping with analysis and structured mining of re-engineering drivers. The "hints" for experience and resolution management are all there in the incident / case data. Time to mine that precious mineral! I urge Services Management Software vendors to ask themselves some simple questions. Does my product help my customer understand the served persona better? For example, does my product help understand which customer (of your customer) is likely to complaint, which customer will opt for other vendors instead of continuing to use your customer's products and / or which customers will provide a low satisfaction score? There are many such questions that services management can help answer. But if you focus on the examples provided here, you will see that each one has implication on prime metrics of your customers - be it cost of servicing or customer retention. These examples can also apply to Employee services management. For example, can we increase employee satisfaction and productivity through proactive reach? Do I understand what kind of proactive support is required for new vs. tenured employees; or remote vs. onsite employees? This could be a mix of new workflows and data driven support to personalize understanding for each customer (install of your software). There is much more to pen here. But let's conclude this blog. I have two main messages for the software vendors in this space: (1) Go beyond predicting MTTR, FCR and shift left, and provide data driven support for improving the quality of service and resolution. This goes much beyond process mining. This is about the risk of providing an early resolution in customer's favor vs. reward in terms of customer lifetime value. This can be done. Hint: Interview customers and classify them for processes and types of resolution. (2) Let's understand the persona we serve, match that understanding with the prime metric of our customers, and provide solutions across (a) persona life cycle (potential to onboarded to engaged/ churned), and (b) service life cycle (proactive to post service) One last thought: This is a topic for another blog but let me send out a teaser. Your product will be stickier if you can measure your customer's success. If you can quantitatively demonstrate the benefits of your products in terms of the customer's prime metric (not MTTR or FCR), you will get more renewals and better customer recommendations. Ask yourself this: Does my product have in-built workflows and dashboards to demonstrate "business benefits"? Can you quantitatively demonstrate that your product helped improve quality and cost of service?

Three tips for success in prepackaging out of box AI apps and use cases. As business applications and platform vendors add more AI based use cases to their products, many have started wondering if the squeeze is worth the juice. If adoption of such use cases by their customers is a measure of success, many have failed and very few can claim success. Having led product teams on both sides of the aisle - vendors of AI use cases and consumers of AI, let me share three tips for success for the vendors of AI apps and use cases. Tip 1: Experience your customer before you build experiences for them: Before you build any experience for your customer, whether it is a UI based experience or a "behind the screen decision support", experience your customer. Do not just understand them, experience them! And while four-hour interviews give you some insights, I have found them insufficient. First, ask if your product managers, data scientists, engineers, go to market team members or anybody else in the chain of delivery have worked as a customer in their career? If you have someone, consider yourself lucky. Learn from their real life experience about the needs of the customer, how they generally organize to meet these needs, what value do they perceive, how important is their voice overall in the organization, do they have sufficient funding to support AI use cases, how do they get human in the loop while using AI, how do they balance human learning with machine learning, what are the day to day issues, what kind of reporting is needed, are there common vested interests and conflicts of interest between personas,.. As you can see there is so much to learn to build AI that works. There is no way a four-hour session would suffice. It may be a good start though. Check with your customer if your team members can shadow real life personas for a week, month, maybe more. Also, you are mass customizing AI. Have that lens always on when you shadow. Not all customers have the same way of working. And that leads me to the second tip. Tip 2: Determine your Customer Decoupling Point (CDP): I define CDP as the point at which the out of box product ends and customer needs to start customizing. This must be looked upon from a customer's point of view. It is the set of out of box product features where mass customization ends, and each customer starts implementing their unique "to-be" scenario. It is that point at which a product starts transforming into a customer solution. Anything beyond CDP is effort, resources, and budget that the customer must pay for. There are many options here: sometimes it is better to keep the CDP away from the customer if you think every customer has unique needs; you could also create industry verticals and bring the CDP closer to the customer; another way would be to standardize certain drop-down lists which brings the CDP closer. After you determine and execute on the CDP, the solution journey starts for your customer. Many call this "the last mile". Tip 3: "The last mile" between CDP and go-live: I have always believed that success of AI (or any other product) depends on how much support is provided in the product for the last mile. The realm of AI products gets a little more difficult when it comes to the last mile. Here's why: Some of your customers might be new to AI environments, others might have matured with AI implementations from home grown data science or other vendors, while others might be on the learning path. You need to provide support in your product that can adjust to all three levels and assume various environments. You might be the only AI apps vendor, or you live with other home grown/ other vendor implementations, or you might be replacing existing implementations. There is a human aspect to this as well. Are you replacing organizational memory (knowledge learnt by folks tweaking deterministic rules), or supplementing it? What does success mean to your customer? How does your product support measure and monitor success? And as you might have guessed from your own experience, I have hardly scratched the surface of "things to consider" here. Simply put, build features that remove the anxiety of implementation/ maintenance, can co-exist with various AI environments, and help your customers measure and communicate value. There are many more tips to share, and more depth to explore in each tip. For now, I would ask to remember the phrase "Experience your customer before you build their experiences", and that should take you on the path of building "Practical AI apps" for your customers - the folks that sign the check.

The third P of my inbound product management framework (Problem > Persona > Purpose > Product) is quintessential. Most often than not, I see product managers jump into the deep end of defining product features and specs after identifying the problem space & related personas. What is often forgotten is the "person" behind the "persona" has a "purpose" for using your product. How do you cater to that purpose to make your product successful? Let me share my four career experiences where I learnt to appreciate the value of "Purpose": My first job was that of a welding engineer in a big engineering company. I was on a crucial defense project which involved a great deal of welding knowledge and expertise. As a fresh graduate, the sense of elation is too small a word to describe the excitement in me. At the shop floor, while welding the seams on this project, I could hardly stop thinking of the numerous people who would be kept safe in it. These folks risk their lives for their country, and it would be more than a shame to know that a weld failed due to manufacturing defects, which cost them their life, and probably the country - a victory! The purpose of the personas using this product made me redefine engineering and testing in a deeply uncompromising manner. Like many in my generation, we began to see software enabling traditional management processes. I was consulting on an ERP implementation. On-the-job training of the transformation was core to this implementation. Accounting employees were to be trained on making ledger entries in the software. While I was enthusiastically pressing keys and entering transactions, I realized my customer was very silent. He had been with the company for decades and knew his job exceptionally well. I saw his silence found a consort with some tears. He viewed this software as a means of replacing his expertise and eventually him. He had no motivation to use the software. Lesson learnt.. "Build purpose into the product". The product had to be built as a means of enhancing his career, not replacing it. Years later, I was leading a team of product managers responsible for various business intelligence applications. We were building Financial Analytics. The first draft of functional specs showed balances of ledger and subledgers in various charts, with the variances highlighted. But did that serve the purpose? The purpose of using that product is for the person behind the persona to quickly tally the ledger with the subledger and go home to his/her family. An efficiency tool that helps reduce the time spent at accounting book closure. And balance variances need to be seen and assessed rather quickly. We had to design analytics that went to the root cause of the variance, scrutinize past learnings and highlight probable reasons for the mismatch in a priority order. Building the extra reports made the product the top seller. Another lesson was while building a product that made the implementer successful. Many implementers had a deep sense of pride from very short implementation time elevating them into change advocates and leaders that aid increased adoption. We developed dashboards that help communicate the value from these implementations. I realized that making the persona successful through this product would automatically make our product successful. The key - think about the persona using your product. What motivates the person? You will surely solve for the `problem space'. Approach the solution in a manner that fulfills the purpose of the persona. This is guaranteed to catapult product adoption. Remember when you expect your user to use your product, you are competing with numerous other priorities & purposes this user is likely to have for the same time he/she spends on your product. Make their time worth it. Build for "purpose" of the person behind your stated personas, and you will be on the path of building products with high adoption. #abhaypracticalAI #machinelearning #artificialintelligence For more on my take, go to my blog: Postingpad - blogs and content for success in artificial intelligence

While this series of posts will be themed around ‘productizing’ AI, I will not be surprised if they apply to productizing any idea or concept. So let’s get into the 4 Ps - Problem, Persona, Purpose , Product. Understanding the problem is important, but most product managers jump into defining product specs after that. To me, understanding the problem is an important first step. It helps you understand the problem space you want to build for, but it is not enough to define product specs. That’s where the next two Ps come to your use. There could be many personas involved with the problem you are trying to solve for. Narrow down the personas you want to build for. This is extremely important before you get to the next P - Purpose. People are the prime movers of any organization. They design and execute on plans. Personas are people (usually). Understand their purpose. What purpose do they serve for themselves, their company, its stakeholders and its customers while working in that problem space. Understanding their purpose will lead you to the next step - Product. Build you product specs to satisfy the purpose, not just the problem. Build for these 4 Ps and in that order; and you will be on your path to building AI products with high adoption. #machinelearning #artificialintelligence #abhayPracticalAI

Sometimes decisions are hard coded using business rules. These business rules get complicated over time. As data, entities and environments change, business rules change. Folks who have coded the rules move on and you are left with a hefty business rule and no documentation. Simple fields like “Whom to contact if there is a problem?” might have a business rule with “if” and “else” clauses spanning various scenarios, usage of words (think reg-ex), entities etc. Example: Contact team A if the problem relates to security of type “facility”, and if location is “A” and if the need is related to “accessing building”. Imagine the complex set of conditions that might come into play if you have 10 teams that need to be contacted under different combinations of conditions. It would be very difficult to manage such business rules. An easier way would be to let AI learn from previous data, and predict the correct team that needs to be contacted. Try identifying ML based rules for decisions that rely on complex and difficult to maintain business rules, and you are on your path towards planning practical AI. #abhayPraticalAI #artificialintelligence #machinelearning

I have often been asked for an easy way to identify use cases for AI. Of the many perspectives possible, one is ”use AI where humans cannot make decisions”. Take the example of predicting CSAT. There are so many variables possible: nature of the transaction, time taken to execute the transaction, sentiment of the interaction, time and day when it happened, entities involved, other opportunities that the customer had to get the same need met, etc. As you can see the number of inputs being considered are too many. Each input might have its own weight in making the CSAT decision. It is also possible that customers fall within segments and each segment has different weights for each input. And these segments might not be as easy to assume as by certain geography, maturity, etc. As you can see it is very difficulty, in fact impossible, for a human brain to predict CSAT under such situations. Identify critical decisions and predictions that may have multiple inputs as candidates for AI, and you will be along your journey for practical AI. #abhayPracticalAI #artificialintelligence #machinelearning

Once you understand the role of AI in meeting the prime metric(s) and purpose of your organization, the next logical step would be to assess the contribution that various processes can make towards fulfilling that role. A good question to ask is “what about the functions/ business processes that I am responsible for, influence the role that AI is expected to play?” For example, if the prime metric is profitability because of increased competition, and if you are responsible for purchasing raw material; may be the answer is “building long term relationship with the vendor helps increase profitability”. Note that the answer may be found several levels deep into questioning. You might start by saying that I need to reduce the cost of procurement, then realize that cost of procurement depends on rejects in raw material, which in turn can be reduced by improving vendor relationship. Once you have a hang of what needs to improve, the next question is how can learning from data help? In this case, may be predicting “type of vendor improvement program best suited for a particular vendor“, or “identifying the likely cause of rejects for a given vendor” might help reduce the chances of reject/returns; thereby improving your profitability. Understand what part of your responsibility impacts the prime metric & purpose, and what you can learn from past data to help improve the same would be a healthy step towards planning for practical AI. #abhayPracticalAI #artificialintelligence #machinelearning

My previous post was about understand and aligning with organizational purpose before defining your AI use cases. Another thing to understand at the organizational level is its primary metric. Not a bunch of KPIs, but just a few - preferably one. This is that one metric (or at best a select few) that can guide processes, people and other resources. For example, assume you are a retail company. And that the uber initiative driving the company’s future is moving from brick and mortar to online sales. Maybe revenue from online sales as a percentage of total sales is your primary metric. Understanding this will help focus your AI use cases towards organization’s benefit. You can then examine process and decisions to understand their role in achieving the goal set for that primary metric. With that clarity, it would be easier to design AI use cases that advance that cause. This might also help you define measurable acceptance criteria for your prediction rule. Link your AI use cases to the primary metric, and you are one step closer to practical AI. #abhayPracticalAI #machinelearning #artificialintelligence