How Banks & Financial Institutions can use Blockchain Technology

Apart from cryptocurrencies, there are several other important use cases for Blockchain technologies in the banking & financial sectors.

NFT 

Non-fungible tokens (NFTs) are new digital assets.  In a nutshell, NFT is a crypto block – which encapsulates digital art or record. The digital art/record is tokenized – just like recording a payment transaction in a blockchain, it becomes a certified true copy – whose authenticity & Ownership can be verified by any node in the crypto-chain network. This token (also called NFT) can then be traded on the blockchain network just like any cryptocurrency.

Today, the world is experimenting with NFT for digital art or digital records. For example, Twitter CEO Jack Dorsey sold his first-ever tweet as an NFT for more than $2.9 million!

Ownership & Transfer of Financial Instruments: 

One of the biggest use cases of NFT in the financial world is recording ownership of financial records: Bond/stock certificates, insurance policies, etc can be tokenized to record the ownership of financial assets, and then these NFTs can be traded on the crypto network.  

Payments, Remittance & Reconciliation

Unlike cryptocurrencies, banks can create & issue crypto tokens that are tied to a fixed value – which can then be transferred over the network for instantaneous payments and remittances without the need for a central bank’s approval. JPCoin is a good example of this.

Servicing of Instruments

Once the ownership of financial assets is tokenized, Payments as per financial contracts such as Bond coupons or dividends can be made programmatically to the current owner of the Financial instrument accurately.   

Storing KYC information & Anti-Money Laundering Registers

KYC information is nonfungible data that can be tokenized so that these records cannot be altered by hackers, and also be used for rapid ID identification across the network for rapid transactions. As the pace of transactions increases, the current data warehousing systems impose certain limitations and the use of NFT for KCY AND AML Registers can speed up global financial transactions.

Regulatory Reporting

Regulatory Reporting should be a nonfungible report as it has major implications. Countries and participating Banks can use the crypto network to get, store and use all regulatory reporting data. These reports can then be shared securely in the crypto database with multiple regulators and other governing bodies. 

Customer Journey Towards Digital Banking

The bank branch as we know it with tellers behind windows and bankers huddled in cubicles with desktop computers, is in need of a massive transformation.

Today. most customers now carry a bank in their pockets in the form of a smart phone app, and  visit an actual branch is not really needed. But banks all over the world are still holding on to the traditional brick-and-morter branches.

Though many banks are closing these branches. In 2017 alone, SBI, India's largest bank closed 716 branches!

Today, despite all the modern mobile technologies, physical branches remain an essential part of banks' operations and customer advisory functions. Brick-and-mortar locations are still one of the leading sales channels, and even in digitally advanced European nations, between 30 and 60 percent  of customers prefer doing at least some of their banking at branches.

While banks like to move customers to the mobile banking platform, changing customer behavior has become a major challenge. The diagram shows the 5 distinct stages of customer behavior and banks must nudge customers to go along this journey.

Steps in Cloud Adaption at Large Enterprises

Large enterprises have bigger challenges when it comes to migrating applications to cloud. Migration to cloud is often an evolutionary process in most large enterprises and is often a 4 step process - but not necessarily a sequential process, and can happen in sequence or on parallel.

Moving to cloud requires a complete buy-in from all business & IT teams: developers, compliance experts, procurement, and security.

The first step is all about becoming aware of cloud technologies and its implications. IT team will need to understand:

1. What are benefits - Agility, cost savings, scalability, etc.
2. What is the roadmap for moving to the cloud?
3. What skills each team member will need?
4. How does the legacy applications work in the future?
5. Who are the partners in this journey?

The second step is all about experimentation and learning from those small experiments. These are typically PoC projects which demonstrates the capability & benefits. The PoC projects are needed to get key stake holder buy-in.

Third step is essentially a migration of existing apps to cloud. For example moving emails to cloud or moving office apps to  Offce365 cloud etc. These projects are becoming a norm for large enterprises - which have a rich legacy.

Fourth step demonstrates  the final maturity of cloud. In this stage, companies now deploy all new apps on cloud and these are cloud only apps.

8 Key Points in a Product Plan

Developing a great product is not an accident. It takes careful planning upfront in developing a Product Requirement Document (PRD).

A good PRD addresses 8 main points which are listed here. This document defines what the product will be, what problem it solves, when it will be ready and how much it will cost. There is no limitation on number of pages the document contain, but it could be comprehensive & concise.

The key to building a great product is to keep this PRD document true to its core intentions. This implies a lot of upfront work, but is absolutely essential for success. If the product is well planned, then only one can build a great product. Oftentimes, it makes sense to develop a user guide as part of the proposed solution – as this helps in developing the product. The amount of work that needs be done upfront is huge – but it aids in every step of product development. Some companies even go into great depths of defining each small step in the project plan with weekly timelines.

"One can achieve greatness with 10000 small steps!"

How Machine Learning Aids New Software Product Development

Developing new software products has always been a challenge. The traditional product management processes for developing new products takes lot more time/resources and cannot meet needs of all users. With new Machine Learning tools and technologies, one can augment traditional product management with data analysis and automated learning systems and tests.

Traditional New Product Development process can be broken into 5 main steps:

1. Understand
2. Define
3. Ideate
4. Prototype
5. Test

In each of the five steps, one can use data analysis & ML techniques to accelerate the process and improve the outcomes. With Machine Learning, the new 5 step program becomes:

1. Understand – Analyze:Understand User RequirementsAnalyze user needs from user data. In case of Web Apps, one can collect huge amounts of user data from Social networks, digital surveys, email campaigns, etc.
   
2. Define – Synthesize: Defining user needs & user personas can be enhanced by synthesizing user's behavioral models based on data analysis.
   
3. Ideate – Prioritize: Developing product ideas and prioritizing them becomes lot faster and more accurate with data analysis on customer preferences.
   
4. Prototype – Tuning: Prototypes demonstrate basic functionality and these prototypes can be rapidly, automatically tuned to meet each customer needs. This aids in meeting needs of multiple customer segments.Machine Learning based Auto-tuning of software allows for rapid experimentation and data collected in this phase can help the next stage.
   
   
5. Test – Validate: Prototypes are tested for user feedback. ML systems can receive feedback and analyze results for product validation and model validation. In addition, ML systems can auto-tune, auto configure products to better fit customer needs and re-test the prototypes.

Closing Thoughts

For a long time, product managers had to rely on their understanding of user needs. Real user data was difficult to collect and product managers had to rely on surveys and market analysis and other secondary sources for data. But in the digital world, one can collect vast volumes of data, and use data analysis tools and Machine learning to accelerate new software product development process and also improve success rates.

Product Management - Managing SaaS Offerings

If you are a product manager of a SaaS product, then there additional things one needs to do to ensure a successful customer experience - Manage the cloud deployment.

Guidelines to choosing the best data center or cloud-based platform for a SaaS offering

1. Run the latest software. 

In the data center or in the IaaS cloud, have the latest versions of all supporting software: OS, hyper visors, Security, core libraries etc., Having the latest software stack will help build the most secure ecosystem for your SaaS offerings.

2. Run on the latest hardware. 

Assuming you're running on your data center, run the SaaS application on the latest servers - like HPE Proliant Gen-10 servers to take advantage of the latest Intel Xeon processors. As of mid-2018, use servers running the Xeon E5 v3 or later, or E7 v4 or later. If you use anything older than that, you're not getting the most out of the applications or taking advantage of the hardware chipset.

3. Optimize your infrastructure for best performance.

Choose the VM sizing (vCPU & Memory) for the best software performance. More memory almost always helps. Yes, memory is the lowest hanging of all the low-hanging fruit. You could start out with less memory and add more later with a mouse click. However, the maximum memory available to a virtual server is limited to whatever is in the physical server.

4. Build Application performance monitoring into your SaaS platform

In a cloud, application performance monitoring is vital in determining customer experience. Application performance monitoring had to be from a customer perspective - i.e., how customers experience the software.

This implies constant Server, Network, Storage performance monitoring, VM monitoring, application performance monitoring via synthetic transactions.

Application performance also determines the location of cloud services. If  customers are in East coast - then servers/datacenters should be in east coast. Identify where customers are using the software and locate the data centers closer to customer, to maximize user experience.

5. Build for DR and Redundancy

SaaS operation must be available 24x7x365. So every component of SaaS platform must be designed for high availability (multiple redundancy) and active DR. If the SaaS application is hosted on big name-brand hosting services (AWS, Azure, Google Cloud etc) then opt for multi-site resilience with auto fail over.

6. Cloud security

Regardless of your application, you'll need to decide if you'll use your cloud vendor's native security tools or leverage your own for deterrent, preventative, detective and corrective controls. Many, though not all, concerns about security in the cloud are overblown. At the infrastructure level, the cloud is often more secure than private data centers. And because managing security services is complex and error-prone, relying on pre-configured, tested security services available from your cloud vendor may make sense. That said, some applications and their associated data have security requirements that cannot be met exclusively in the cloud. Plus, for applications that need to remain portable between environments, it makes sense to build a portable security stack that provides consistent protection across environments.

Hybrid SaaS Offering

Not all parts of your SaaS application can reside in one cloud. There may be cases where your SaaS app runs on one cloud - but pulls data from other cloud. This calls for interconnect between multiple cloud services from various cloud providers.

In such hybrid environment, one need to know how apps communicate and how to optimize such a data communications. Latency will be a critical concern and in such cases, one needs to build in a cloud interconnect services into the solution.

Cloud Interconnect: Speed and security for critical apps

If the SaaS App needs to access multiple cloud locations, you might consider using a cloud interconnect service. This typically offers lower latency and when security is a top priority, cloud interconnect services offer an additional security advantage.

Closing Thoughts

SaaS offerings has several unique requirements and needs continuos improvements. Product managers need to make important decisions about how the applications  are hosted in the cloud environment and how customers experience it. Making the right decisions gives the results for a successful SaaS offering.

Finally, measure continuously. Measure real-time performance, after deployment, examining all relevant factors, such as end-to-end performance, user response time, and individual components. Be ready to make changes if performance drops unexpectedly or if things change. Operating system patches, updates to core applications, workload from other tenants, and even malware infections can suddenly slow down server applications.

Product Leadership

Product leadership is all about answering 5 questions.

1. What is the problem?
2. Why solve it?
3. When is it needed?
4. How to solve it?
5. With what tools?

Leadership must provide all the answers to these 5 questions and the answers to these five questions must be a shared & must be common among all stake holders working on that product.

Success of the product depends on how well the organization answers these questions. As you can see there is no right or wrong answer and the organization is judged on how good the answers were!

Product Management for Enterprise products

Even if you're a seasoned product manager, from the business model to the meaning of the word "customer," building products for companies is substantially different than building products for consumers. Here's why.

Product is hot. If you pay attention to the tech industry at all, you know what we're talking about. "Product manager" is one of the most highly-coveted job titles for new MBA graduates. Entire blogs, newsletters, conferences, even boot camps have sprung up around the tech world catering to people interested in the topic. Try putting "product manager" in your LinkedIn profile, and get ready to see a steady uptick in your recruiter spam. There is, in fact, a whole content and social network called Medium dedicated solely to sharing product management thinkpieces.

Yet we still have difficulty explaining to our parents what we do for a living. Neat summaries or the kind of pithy clichés ("the product manager is like a mini CEO!") you often see are either silly or, at best, very incomplete. We're not engineers. Nor are we marketers. We're certainly not "CEOs of the product." But we're the guys who everyone else looks to when there's a question about our products, or "how it's doing," or "what it needs" or "what [it/we] need to do next." And we better have a good answer for those questions, because we're ultimately the only guys whose responsibility it is to know.

In a mature, high-functioning software business, you have a lot of teams hustling around different aspects of a product (or group of products):

There is obviously engineering, which not only builds what they're asked to build, but tests and patches it for stability, quality, defects, and more.

In Software as a Service (SaaS) businesses like ours, there's an operations team that monitors the cloud platform and customer tenants and works closely with engineering (hi there, DevOps!) on releases.

There's sales, the folks who actually breathe life into your business. Sales can encompass everyone from lead development reps, or LDRs (sometimes called account development managers or similar) to account executives, to customer success managers, to sales engineers (or solutions consultants), all of whom are dedicated to acquiring, growing, and keeping business.

Marketing, whose array of specialty functions can be dizzying: digital, content, demand generation, social, events, brand, product and solution, and more.

There are "foundational" services like finance, legal, and even IT, that are easily overlooked but absolutely essential to making everything run. And there are plenty more besides.

Right at the nexus of all of these teams—neither above nor below, but working as a peer—is product management. "Product" leads in defining the product vision, establishing the operational plan to get there, and then executing on it. It harnesses the incentives built in to all of the other teams and aligns them toward a single destination. In this way, "PM" is an operational role, not really a technical or specialist one. If you'll permit us just one pithy metaphor, the product manager is a sheepdog; we don't necessarily dictate the destination, especially in business terms (an executive team often does that), but we generate a route to get there, a "roadmap," if you will, in terms each team understands.

We're also no one's boss. Product typically works with other teams, not over them. The product manager is no one's CEO and usually works with little or no formal authority to tell anyone what to do. Indeed, in most software companies, and particularly in enterprise software, one of product management's core functions is this cross-functional collaboration with many different teams to make sure that the team as a whole moves in the right direction.

In most high-functioning organizations, other teams rely on Product to help them do their jobs more effectively. Development relies on product management to define a plan and write user stories, requirements, and acceptance criteria that explain what needs to be built. Marketing relies on Product for product information, value proposition definitions, business case material, market intelligence and, sometimes, content. Sales relies on Product for much of the same, plus determining target market segments, demo cases, answering detailed inquiries, and helping to close deals. Finance and Product rely on each other to build the business through determining pricing, margins, discounting, and so forth. Leadership relies on Product for execution on overall product and business strategy. Across all of these cases, Product is the key index and what keeps all of them churning toward the same destination.

The tech landscape is just so broad, especially when you consider both consumer and enterprise segments, that we doubt if it's very useful to distill the product management function down into just one definition. No two companies will use the product management in exactly the same way. Perhaps being the "sheepdog" doesn't resonate with you. If not, we bet this will:

A friend of ours, Matt LeMay,1 was recently teaching one of his excellent courses on product management for O'Reilly. In it, he gave his students a quick learning exercise: he separated them into teams, representing different parts of the aforementioned business. He gave each of them certain resource restraints and a finite timeline in which to solve a product quandary. After a period of negotiating with one another, they came back to him, harried, confused, and a little panicked: "There's just not enough time!" they cried. "We can't complete all of these requirements, in sequence, in the time window you're asking for! What do we do first?"

After he explained this ingenious exercise to us, we laughed, because we all got the joke. "Welcome to product management!"

Three Things that Make Enterprise Software Different

There are really three big elements that make product management in enterprise software different: our business model, our specialization, and the split between our customers and users.

1. The Business Model

In consumer technology, there are lots of revenue models; advertising-supported is obviously very popular, but there are also two-sided marketplaces, affiliate models, direct sales (almost always self-service ones), and much more. In the winner-take-all world we live in today, all of these are fundamentally scale businesses. You have user bases in the millions (or tens, or hundreds thereof) and must make product, pricing, infrastructural, and technology decisions accordingly.

In the enterprise market, we operate almost exclusively on a direct-sales model, whether that means selling good old-fashioned licenses or subscriptions (as we do in SaaS). Enterprise is rarely a scale business. Though there are interesting exceptions, we mainly rely on direct sales to sell complicated products and solutions to a relatively small (compared to consumer software) group of sophisticated customers for large deal sizes. Those deals are negotiated, budgeted, implemented, and monitored for weeks, months, or even years! Sales cycles are long and complicated. (You can probably already see some obvious reasons why it can be very difficult for startups to crack this market.)

2. Product Specialization

Enterprise software is usually also very specialized and tailored to serving a specific technical or business need. Think CRM, business analytics, or data management. These are solution areas that become very complicated, very quickly. Our challenge as product managers is not only to make these tools deliver more business value over time with new features, capabilities, integrations, and so forth; it's also to understand how our users work, what their jobs and industries are like, and how our products fit into their lives. This is especially true after your product breaks out of the "point solution" category (i.e., meeting a very specific, constrained business need) and grows to encompass multiple different use cases, roles, or industries. (We talk about platforms versus products later on in the book.)

3. The Customer versus the User

The last big thing that makes "enterprise PM" tricky is who we're building for. Our users, who might spend a substantial chunk of their professional lives working in our product's user interface (UI), are almost never the same people who actually pay us for it. Our users work directly with our product to perform some function that allows them to do their jobs better, more easily, or efficiently. Our customers, by contrast, are nearly always those users' bosses (or their bosses, or even their bosses' bosses) who write the check.

When you're selling a product that has a five-, six-, or even seven-figure price tag, it's going to be an executive, not infrequently a C-level one, who has the budget juice to pull the trigger. These types of customers have a very different set of selection criteria than their direct reports, our users, who will actually be using our product day in and day out. Broadly speaking, they tend to care more about hard business results and return on investment (ROI) than a high-design UI and feature checklists. In our experience, they might touch the product in question, but they do not live in it day in and day out.

In some cases, your users might exert a strong influence on your executive customers. Executives might short-list a set of potential solution vendors with their department's input, or, often, they might have used a preferred vendor's product before. For scenarios in which the products in question are highly sophisticated and require specialized training or experience, this is more likely the case. Alternatively, there are lots of cases in which executive customers make their choices based on basic functionality and price, with little or no regard for user input (think call center or large retail point-of-sale software).

Very clearly understanding your user and your customer and how those two interact and influence each other is absolutely vital to being successful as an enterprise project management.

Should you focus on more powerful or flexible user features? An ultra-sleek UI? Expanded mobile support and great notifications? Or do you target additional integrations and adjacent capabilities that can provide "good enough" functionality to allow your customer to end their contract with a competitor? There is probably an infinite list of projects you could spend time on, but choosing which of these two stakeholders to over-serve, and how, will depend on you, the product manager, understanding which is going to best drive your product's success.

Are You Selling to Users First, or Customers?

There are some companies that make a deliberate strategy of conquering their market's total user base community as a backdoor into enterprises of all sizes. A "hearts and minds" route like this is a high-touch and often high-investment strategy requiring a product focus on the user experience (UX), great design, clear features, ample documentation, simple onboarding, and, often, a very heavy marketing spend. By evangelizing the product among subject matter experts (SMEs) and enthusiasts to make it a popular favorite, they're really relying on these communities to indirectly pressure the big companies they work for to "get with the times."

By contrast, other companies are renowned for having a direct line to the executive suite. They rely on brand and solution-level marketing, long-term relationships, executive-focused "thought leadership," and sheer sales savvy to capture business at the C-suite level. (These are the guys whose ads blanket every major airport.)

These strategies are rarely clearly articulated as such, but it's usually pretty obvious which one your company is taking. They are both proven, successful methods for winning a market. Each one has a quite different set of product implications that enterprise project managers should clearly understand.

Clearly differentiating between our users versus customers reveals a layer of subtlety to the problems the product solves, and therefore the value it offers. Whose problems does our product chiefly address? Our users or customers? Striking the right balance of that value will depend on your reading of your market and product strategy. One way to begin that process is to prioritize the problems we want the product to address. So, get ready for a deep-dive in the next chapter into a discussion of whose problems you're really solving.

Closing Thoughts 

Product management for enterprise software is crucially different than for the consumer market. Not only must we differentiate between our enterprise product's user and customer and the needs for each party that must be met, but our product's route to market and the way customers plan for and buy it are completely different from consumer software. Moreover, enterprise software typically operates with a completely different business model than consumer-facing businesses. All of these differences have significant upstream consequences for how enterprise products need to be planned, built, sold, distributed, and serviced.

Basics of Text Analytics

Factors Impacting Software Product Pricing

Product Management in Sustaining Products

Every product goes through its natural product lifecyle. After the initial release - ver 1.0, it rapidly goes through mass adaptation and then most often a product goes into a long period of sustenance - where there are few incremental features being added and new platform support being added to keep the product relevant to the marketplace.

Product management in this phase where the product is jut being sustained is just as important as its initial creation. This is the time where the product generates the highest profits. It is therefore very important for product managers to be very prudent and efficient in managing the product.

To be very successful in this life stage of the product, one needs to adapt management by metrics approach and here there are four main metrics:

1. Time to Market
2. Development Costs
3. Defect Rates
4. Support Costs

Figure-1: An illustration of main metrics

The main focus of product management here is to ensure that these metrics are heading in rapid downward trends. For example, the objective may  be to reduce the defect rates by 73% (when compared to the baseline version - usually ver 3.0 or the version which defined the product)

These metrics then become the driving factors for new development - i.e., incremental development of the product.

At this stage of product lifecycle, it is very important to adapt agile practices: Agile product management, Agile product development and Agile leadership to lower the costs of sustaining the product in a very significant manner and increase the profits from the product.

Thus make the core cost centers as the key profit center!

Product Management 101 - Customer validation is the key

Recently, I was having lunch with a co-founder of a startup in Bangalore. They have a vision which sounds good on the surface: Provide data loss protection on Cloud. Though this sounds as such a old & proven idea, they have a very good secret sauce which gives them a unique value proposition: Security, Cost benefits & much better RPO/RTO than competition.

Like most entrepreneur, he started out by validating his product idea with customers. Starting with customer survey, asking customers about their pain points and asking them:  "If this product solves your problem, will you buy it?"

Customer validation is a good point to start, but one must also be aware that such a survey can lead to several pitfalls.

1. Customer needs could change with time, and are no longer interested when the product is launched.
2. Customer just expressed his 'wants' and not his 'needs', and may not pay for the actual product.
3. Customer has no stake in the product. Just answering few questions was easy - there was no commitment or risks.

All this risks imply that customer validation may result in false positives.

False positive is a known risk factor in new product development and startups often take such risks. In case of my friend's startup, he took that risk and decided to invest in developing a prototype.

Several months have gone by and his company is busy building the prototype and his biggest fear is that customers may not embrace his product and is constantly changing what should be his MVP - Minimum Viable Product.

What is a Minimum Viable Product?

A minimum viable product (MVP) is the most pared down version of a product that can still be released. An MVP has three key characteristics:

It has enough value that people are willing to use it or buy it initially.
It demonstrates enough future benefit to retain early adapters.
It provides a feedback loop to guide future development.

The idea of MVP is to ensure that one can develop a basic product which early adapters will buy, use & give valuable feedback that can help guide the next iteration of product development.

In other words, MVP is the first version of a customer validated product.

The MVP does not generate profits, it is just a starting point for subsequent product development - which in turn results in rapid growth and profits.

Customers who buy the MVP are the innovators & early adapters, and no company can be profitable serving just the early adapters. But a successful MVP opens the pathway towards the next iterations of the product which will be embraced by majority of customers: 'Early Majority', 'Late Majority' and 'Laggards'.

MVP is also expensive for startups

For a lean startup, developing a MVP can be expensive. MVP is based on: Build -> Measure -> Learn process - which is a waterfall model.

There are two ways to reduce risks associated with developing an MVP. One way to reduce risks is to avoid false positives.

While conducting market research during customer validation process, one must ensure that customer is invested in this product development.

At the first sight, it is not easy to get customer to invest in a new product development. Customers can invest their Time, Reputation &/or Money.

By getting customers to spend time on the potential solution to their problem is the first step.

Second step would be get them invest their reputation. Can customer refer someone else who also has the same problem/need? Is the customer willing to put his name down on the product as the Beta user? Getting customer invest their reputation would most often eliminate the risks of false positives.

One good way to get customers invest their reputation is to create a user group or community - where customers with similar needs can interact with each other and new product development team - while helping new product development.

In case of B2B products, customers can also invest money in new product development. Getting customers to invest money is not so tough. I have seen this happen in several occasions. I call this co-development with customers (see my blog on this topic)

Kick Starter programs have now taken hold and today startups are successfully using kick starter programs to get customers invest money in their new product development.

Accelerating the Development Cycle & Lowering Development Costs

A lean startup should avoid developing unwanted features.

Once customers are invested in this new product, the startup will usually start developing the product and march towards creating the MVP.  However, it is common to develop a product and then notice that most customers do not use 50% of the features that are built!

Lean startup calls for lowering wastage by not building unused features. The best way to do this is to run short tests and experiments on simulation models. First build a simulation model and ask customers to use it and get their valuable feedback. Here we are still doing the Build -> Measure -> Learn process, but we are doing it on feature sets and not the entire product. This allows for a very agile product development process and minimizes waste.

Run this simulation model with multiple customers and create small experiments with the simulation model to get the best possible usage behavior from customers. These experimental models are also termed as Minimum Viable Experiment (MVE), which forms the blue print for the actual MVP!

Running such small experiments has several advantages:

• It ensures that potential customers are still invested in your new product.
• Helps develop features that are more valuable/rewarding than others.
• Build a differentiated product - which competes on how customers use the product, rather than having the most set of features.
• Helps learn how users engage with your product.
• Help create more bang for the buck!

Closing Thoughts

In this blog, I have described the basic & must-do steps in lean product development, which are the fundamental aspects of product management.

Customer validation is the key to new product success. However, running a basic validation with potential customers runs a big risks of false positives and investing too much money in developing the MVP.

Running a smart customer validation minimizes the risks while creating a lean startup or lean product development. A successful customer validation of a solution helps to get paying customers who are innovators or early adapters. This is first and most important step in any new product development - be it a lean startup or a well established company.

Key Product Management Principle - People are the core Asset

2017 is turning out to be a tumuntous year for IT industry worldwide. Large established IT companies such as Cisco, HPE, Dell-EMC, IBM are serious cutting down costs.  Unfortunately, companies tend to look at people as "expenses" and layoffs have become common.

Product managers have From a product managers often answers three main questions:

1. Where is the Product Today?
2. Where do we want to take the product & by what time?
3. How can the team get the product there?

Therefore, product managers have a different view when it comes to employees. From a product development perspective, people are "assets" - especially engineering teams and customer facing teams. Success of new product development depends of people.

Product managers treat people as true assets as the success of the new products - which creates future revenue for the company. Without people, the new product will never be able to reach its intended goal.

In IT, engineers and their intellect, skills, knowledge, character, integrity are - the true value in any organization. Because of the nature of IT product development, it is vital that product managers treat their engineering colleagues as true assets.  Product manager must spend time with the team. This means talking with them, listening to their concerns and fears about the current phase of the project, and occasionally taking them out for lunch. ( Lunch is a truly amazing way to motivate people)

Product managers have to make the team members feel valued. That's when engineers they care more about the product on which they are working. Face-time with the team also helps product managers understand individuals and personally assist them. Time spent with the team pays financial dividends as high-quality products make it to market on time and with enough vitality to excite the sales force.

Closing Thoughts

When product managers focus on the people with whom they work, the products succeed as a result.

Can Apple Revive iPad and make it great again?

I have had an iPad 2 for nearly 5 years now and it still works great. I have not felt a need to upgrade it either. The fact that the old iPad works so well is great, but it also indicates a BIG short coming in product planning by Apple. (Samsung has not done great either with its Samsung Tab)

Eons ago, Apple released a groundbreaking product called iPad which sold hundreds of millions of units and customers loved it. After few years of increasing sales, gravity seems to have taken over iPad sales and now the sales of iPad is dropping every quarter.

The product is so good that it does not breakdown and customers like me are happy using it even after 5 years.

The fact that my iPad has outlasted my laptop made me think over it.

When I bought my first iPad, I thought the next version of iPad will surely replace my laptop. Few months later, I got another one for my daughter and my wife got a Samsung Tab.

Both iPads and Samsung Tab still do a great job & I see no reason to replace it with newer models. I read books, browse web, read gmail etc., But the usage is limited. For other creative work, I still need a laptop. For example, I am typing this article on a laptop!

In my opinion, iPad missed several great opportunities to be a perfect replacement for a laptop and a Television. I think, Apple is struck with an unresolved dilemma. Is iPad a computing device? Or is iPad an entertainment device? Should iPad evolve to replace laptops? Or should iPad evolve to replace Televisions?

To me, this is similar to the dilemma faced by Yahoo!  Is Yahoo a media company or is Yahoo a technology company! Yahoo was unable to resolve this dilemma and died. Hopefully Apple can do better.

Long ago, I saw iPad as a computing device which would replace my laptop as a primary computing device. But my daughter uses it as a game console and entertainment device. In both cases, iPad still has not been able to progress much.

Path Ahead for Apple

Putting my product management hat, the best I can recommend is to split iPad into two distinct product lines.

1. Expand the compute capability & make it a preferred compute platform.

2. Expand screen size and make iPad a perfect personal TV Platform.

iPad as a Compute platform

With ever increasing CPU power and memory sizes, iPad can be expanded with a better keyboard, and mouse to replace the laptop. Increasing CPU power.

Apple always supported Bluetooth keyboards and it works, but the real issue was with the pointing device. The Apple pencil and Styli is awkward and has never taken off as a pointing device, this needs to be fixed in the future release. Maybe a bluetooth mouse perhaps?

In addition, Apple needs to beef up its app offerings to support better content creation tools - either via a VDI platform or native content creation apps. Today, modern ARM based mobile CPUs have enough compute power to support content creation.

These two can be easily addressed by Apple.

The real big problem is the screen size.

Increasing the screen size to a 11" or a 12" will make iPad bigger and cumbersome to handle. iPad has long supported external displays - via AirPlay protocol, but it was always cumbersome and one had to carry a big bag full of accessories for a small iPad. Instead, the solution is to allow iPad to operate multiple screens - like Windows & OS-X.  Ideally having apps adapt to any screen wirelessly without a docking station will make it ideal device as a workplace productivity tool. Users can use both the iPad screen and an external screen to do their job.

iPad as an Entertainment platform

In the entertainment version of iPad, iPad can leverage wireless connectivity to a larger screen and also support multiple screens - like a VR headset - will help iPad become more relevant to the future of entertainment world.

When it comes to gaming, I would like to see iPad support different wireless gaming controllers - via Bluetooth or wireless USB. This would allow users to use a bigger 48"-96" TV screens for gaming via iPad.

Support for multiple screens will also aid in entertainment usage. One person can watch a video being casted on TV while other watches another video on iPad screen.

Closing Thoughts 

Once iPad makes these changes, app developers will enhance their apps to support such flexible options with large-screens, VR headsets etc., and it usher in a new era in home entertainment, while keeping the base iPad's portability and all day battery usage.

iPad is a great device and can reach greater heights. Apple just needs to evolve this into two distinct platforms to make fit better into more people's divergent needs.

Introduction to Microservices

Microservices are a type of software architecture where large applications are made up of small, self-contained units working together through APIs that are not dependent on a specific language. Each service has a limited scope, concentrates on a particular task and is highly independent. This setup allows IT managers and developers to build systems in a modular way. In his book, "Building Microservices," Sam Newman said microservices are small, focused components built to do a single thing very well.

Martin Fowler's "Microservices - a Definition of This New Architectural Term" is one of the seminal publications on microservices. He describes some of the key characteristics of microservices as:

Componentization: Microservices are independent units that are easily replaced or upgraded. The units use services to communicate with things like remote procedure or web service requests.

Business capabilities: Legacy application development often splits teams into areas like the "server-side team" and the "database team." Microservices development is built around business capability, with responsibility for a complete stack of functions such as UX and project management.

Products rather than projects: Instead of focusing on a software project that is delivered following completion, microservices treat applications as products of which they take ownership. They establish an ongoing dialogue with a goal of continually matching the app to the business function.

Dumb pipes, smart endpoints: Microservice applications contain their own logic. Resources that are often used are cached easily.

Decentralized governance: Tools are built and shared to handle similar problems on other teams.

History of microservices

The phrase "Micro-Web-Services" was first used at a cloud computing conference by Dr. Peter Rodgers in 2005, while the term "microservices" debuted at a conference of software architects in the spring of 2011. More recently, they have gained popularity because they can handle many of the changes in modern computing, such as:

• Mobile devices
• Web apps
• Containerization of operating systems
• Cheap RAM
• Server utilization
• Multi-core servers
• 10 Gigabit Ethernet

The concept of microservices is not new. Google, Facebook, and Amazon have employed this approach at some level for more than ten years. A simple Google search, for example, calls on more than 70 microservices before you get the results page. Also, other architectures have been developed that address some of the same issues microservices handle. One is called Service Oriented Architecture (SOA), which provides services to components over a network, with every service able to exchange data with any other service in the system. One of its drawbacks is the inability to handle asynchronous communication.

How microservices differ from service-oriented architecture

Service-oriented architecture (SOA) is a software design where components deliver services through a network protocol. This approach gained steam between 2005 and 2007 but has since lost momentum to microservices. As microservices began to move to the forefront a few years ago, a few engineers called it "fine-grained SOA." Still others said microservices do what SOA should have done in the first place.

SOA is a different way of thinking than microservices. SOA supports Web Services Definition Language (WSDL), which defines service end points rigidly and is strongly typed while microservices have dumb connections and smart end points. SOA is stateless; microservices are stateful and use object-oriented programming (OOP) structures that keep data and logic together.

Some of the difficulties with SOA include:
SOA is heavyweight, complex and has multiple processes that can reduce speed.
While SOA initially helped prevent vendor lock-in, it eventually wasn't able to move with the trend toward democratization of IT.

Just as CORBA fell out of favor when early Internet innovations provided a better option to implement applications for the Web, SOA lost popularity when microservices offered a better way to incorporate web services.

Problems microservices solve

Larger organizations run into problems when monolithic architectures cannot be scaled, upgraded or maintained easily as they grow over time. Microservices architecture is an answer to that problem. It is a software architecture where complex tasks are broken down into small processes that operate independently and communicate through language-agnostic APIs.

Monolithic applications are made up of a user interface on the client, an application on the server, and a database. The application processes HTTP requests, gets information from the database, and sends it to the browser. Microservices handle HTTP request response with APIs and messaging. They respond with JSON/XML or HTML sent to the presentation components. Microservices proponents rebel against enforced standards of architecture groups in large organizations but enthusiastically engage with open formats like HTTP, ATOM and others.

As applications get bigger, intricate dependencies and connections grow. Whether you
are talking about monolithic architecture or smaller units, microservices let you split
things up into components. This allows horizontal scaling, which makes it much easier to
manage and maintain separate components.

The relationship of microservices to DevOps
Incorporating new technology is just part of the challenge. Perhaps a greater obstacle is developing a new culture that encourages risk-taking and taking responsibility for an entire project "from cradle to crypt." Developers used to legacy systems may experience culture shock when they are given more autonomy than ever before. Communicating clear expectations for accountability and performance of each team member is vital. DevOps is critical in determining where and when microservices should be utilized. It is an important decision because trying to combine microservices with bloated, monolithic legacy systems may not always work. Changes cannot be made fast enough. With microservices, services are continually being developed and refined on-the-fly. DevOps must ensure updated components are put into production, working closely with internal stakeholders and suppliers to incorporate updates.

The move toward simpler applications.

As DreamWorks' Doug Sherman said on a panel at the Appsphere 15 Conference, the film-production company tried an SOA approach several years ago but ultimately found it counterproductive. Sherman's view is that IT is moving toward simpler applications. At times, SOA seemed more complicated than it should be.

Microservices were seen as an easier solution than SOA, much like JSON was considered to be simpler than XML and people viewed REST as simpler than SOAP. We are moving toward systems that are easier to build, deploy and understand. While SOA was initially designed with that in mind, it ended up being more complex than needed.

SOA is geared for enterprise systems because you need a service registry, a service repository and other components that are expensive to purchase and maintain. They are also closed off from each other.

Microservices handle problems that SOA attempted to solve more than a decade ago, yet they are much more open.

How microservices differ among different platforms
Microservices is a conceptual approach, and as such it is handled differently in each language. This is a strength of the architecture because developers can use the language they are most familiar with. Older languages can use microservices by using a structure unique to that platform. Here are some of the characteristics of microservices on different platforms:

Java
Avoids using Web Archive or Enterprise Archive files
Components are not auto-deployed. Instead, Docker containers or Amazon Machine Images are auto-deployed.

Uses fat jars that can be run as a process

PHP
REST-style PHP microservices have been deployed for several years now because they
are:

• Highly scalable at enterprise level
• Easy to test rapidly

Python

• Easy to create a Python service that acts as a front-end web service for microservices in other languages such as ASP or PHP 
• Lots of good frameworks to choose from, including Flask and Django
• Important to get the API right for fast prototyping 
• Can use Pypy, Cython, C++ or Golang if more speed or efficiency is required.

Node.js
Node.js is a natural for microservices because it was made for modern web applications.
Its benefits include:

• Takes advantage of JavaScript and Google's high-performance, open-source V8 engine
• Machine code is optimized dynamically during runtime
• HTTP server processes are lightweight
• Nonblocking, event-driven I/O
• High-quality package management
• Easy for developers to create packages
• Highly scalable with asynchronous I/O end-to-end

.NET

In the early 2000s, .NET was one of the first platforms to create applications as services
using Simple Object Access Protocol (SOAP), a similar goal of modern microservices.
Today, one of the strengths of .NET is a heavy presence in enterprise installations. Here
are two examples of using .NET microservices:

• Building a .NET self-hosted web service using Open Web Interface for .NET (OWIN). You can then use it to incorporate microservices.

• Setting up a fictional Human Resources firm

Responding to a changing market

The shift to microservices is clear. The confluence of mobile computing, inexpensive hardware, cloud computing and low-cost storage is driving the rush to this exciting new approach. In fact, organizations do not have any choice. Matt Miller's article in The Wall Street Journal sounded the alarm; "Innovate or Die: The Rise of Microservices" explains that software has become the major differentiator among businesses in every industry across the board. The monolithic programs common to many companies cannot change fast enough to adapt to the new realities and demands of a competitive marketplace.

Service-oriented architecture attempted to address some of these challenges but eventually failed to achieve liftoff. Microservices arrived on the scene just as these influences were coming to a head; they are agile, resilient and efficient, qualities many legacy systems lack. Companies like Netflix, Paypal, Airbnb and Goldman Sachs have heeded the alarm and are moving forward with microservices at a rapid pace.

Why Fintech needs Modern Authentication systems?

Fintech essentially runs mostly on cloud & mobile platforms to reach out a wide range of customers. Recently, I was asked to create a technical solution for authentication for cloud+mobile fintech solution for SMB market.

User authentication is a key security feature for this fintech platform. It is therefore important to document the key points in identifying key requirements and factors that drive the final solution.

Requirements has to be identified from Strategic, Business user requirements & IT Operations requirements.

On a side note, I had blogged on the need for Multi Factor Authentication as a Service in December 2011, and many of the points I had noted in that blog is very relevant for Fintech services.

Strategic Requirements

From a Fintech point of view, the top priority for Authentication system must meet security requirements - i.e., Reduce the risk of Breach. Cost of a security breach is much bigger than the immediate financial losses. The legal implications and loss of customer trust can be a business killer.

Second most important Strategic requirements is to lower costs. The main benefit of fintech is that it offers lower costs for financial transactions, while speeding up the rate of transactions. So cost of authentication is very critical for the business plan. The low cost becomes very imperative when we consider IoT, robotics & automation systems will also use the same authentication system. This implies the authentication system must be able to scale to support very very large number of users.

Today Fintech solutions should disrupt existing financial process and this disruption is achieved by accelerating the rate of financial transactions. This forms the third strategic requirement for authentication systems. The solution must accelerate digital transformation.

In the automation or intelligent software space, robotic process automation tools, automation tools, and cognitive computing solutions create change inside organizations.

The three strategic requirements can be summarized in on sentence: Provide a low cost authentication system which is safe, secure, user friendly solution that can be used on multiple devices by users anywhere in the world.

In a nutshell, the authentication system must allow users to securely, from anywhere, on any device they happen to use and over any type of network.

Existing Solutions & Legacy solutions

Having worked in EMC and used RSA's SecureID authentication system, I know the pro's and con's of legacy systems.

I remember the days when CFOs would carry around a box full of secureID fobs - one each for each bank accounts and then dealing with the headache of tracking which secureID token for which account.

Legacy authentication systems works with traditional bank IT systems, and these are proven solutions. But in the new world of Fintech, these legacy systems are no longer useful. The legacy systems are expensive, slow & cumbersome to use and slows down the rate of transactions.

Legacy two factor authentication solutions have their limitations: Poor user experience - with hardware tokens/fobs, additional passcodes & signin steps. Moreover the legacy systems are also expensive to buy and operate. Not counting the complexity in deploying, maintaining and administering the solution.

If Fintech were to truly disrupt existing workflows, we need to look beyond the standard Two-Factor-Authentication systems - which uses Smart tokens, smartcard or hard tokens.

Fintech requires more secure and yet easy to use authentication solutions. The solution has to be highly scalable and yet allow higher rates of transactions.

Today, Fintech solutions need to know more than just the two proofs of identity for access the system. Fintech solutions needs to know the context & geo-location information in addition to password and a dynamic password.

In a nutshell, legacy two-factor authentication system does not work for Fintech. While we will still need a two factor authentication, the system must be go beyond the passwords/keys, and also understand the user context and risks/vunerabilities.

Next Generation Authentication System

Fintech services will need a cloud based authentication system - which offers Authentication-as-a-Service model but it also needs to meet some of the following requirements.
From Fintech point of view, there are three main requirements categories.

1. Business Requirements
2. IT Requirements
3. User Requirements

Business Requirements 

Fintech solutions need stringent security requirements that can meet new threats and opportunities. Fintech solutions will have to federate between multiple applications and services across the ecosystem of customers & partners.

From a business point of view, the cloud based authentication system must meet or exceed industry standards - Oauth 2.0, OpenID Connect 1. 0, SAML & FIDO. Support for open identity authentication standards ensures these requirements are met. Meeting industry standards will allow businesses to leverage their investments, integrate with legacy systems, external data sources and third-party cloud applications.

A cloud based authentication system allows easy, frictionless experience which users expect. Cloud based systems also provide easy interop with third party systems/domains - which allows your company to operate smarter, create value and strengthen competitive advantage. The cloud based system should also scale to meet requirements as the business grows.

For a Fintech cost of solution must be very low. As mentioned earlier, legacy hardware token based systems are too expensive. One-time-passcodes (OTP) pushed over SMS can also generate quite a high costs over a period of time, and NIST recommends against using out-of-band authentication system using SMS.

It is important to allow customers to login even when they are offline or on unreliable networks. This implies that the authentication system must have the intelligence to know the context of the user and choose the right authentication methods.

Contextual and Risk-based Authentication is the key to lower costs while improving customer experience. Authentication system must know the geo-location, time of the day, IP Adderesses, Device identifiers to ascertain the risks of unauthorized logins and then implement adequate security policies to prevent security breaches.

In short, an intelligent context based authentication should provide a strong, adaptive authentication.

For example, For a regular user, if there was a authentication attempt was done from a country out of the region from the last known geolocation, then the system must trigger other authentication/validation processes.

IT Requirements

IT systems which manages & operates the authentication system is the key to ensure customer satisfaction and accelerate digital transformation of Financial services - which is the core value of Fintech solutions.

Fintech customers/users should be able to use any device, from any location to get their work done. This implies that traditional mobile device management solutions (MDM) and VPN technologies will not work as the solutions are too rigid and does not scale rapidly.

A cloud based authentication system - which can be centrally administered will be needed. The an intelligent context based authentication would provide a strong, adaptive authentication to users & partners, while providing adequate security to allow both managed and unmanaged mobile devices which are used.  Giving users access to the information and insights they need, when and where they need it, allows your company to operate smarter, create value and strengthen competitive advantage.

IT plays a very important role in management & administration of user authentication system. Web-based administrative access and policy/role based entitlements is a must to automate new user additions.

IT administration functions must be automated to the maximum, and allow self-service where ever feasible. The authentication system must ensure that IT administrators can intervene using administrative bypass codes to help customers/partners when needed - such as a customer escalation or when administrative intervention is needed.

Authentication systems must also provide varied levels of trust, varied levels of access and permissions. Support for role based access and web based access for IT administrators is important to address customer issues.

In Fintech world,  partners are the key for success. Authentication system should work with partners - to increase efficiency and add greater value. Authentication system should enable strong authentication service to partners through traditional VPN systems or modern cloud services.

User Requirements

Users form the basis for Fintech services. Without users, there is no business. Therefore user requirements are very critical.

Today, customers user a wide variety of devices - Mobiles, tablets, laptops - running iOS, Android, Windows, Linux etc. The web based authentication must support heterogeneous environments and keep up support to newer platforms. Web based authentication system must allow users to authenticate over multiple devices - and even when they don't have their primary devices. For example, user should be able to borrow a smart phone to make a payment from his account.

In today's Fintech world, Authentication system must work on a global scale as well and support multiple languages and locale settings. The authentication system will have to be resilient security to overcome any denial of service attacks and other hacks

Today Customers are accustomed to self-services. Self-service enrollment and registration mechanisms lighten the IT team's administrative load and accelerate user adoption. Offer multiple fault escalation processes to enable authentication when a user cannot authenticate under their normal process.

Closing Thoughts 

Fintech will bring in a new wave of digital transformation. For Fintech to succeed, it is important to provide secure access through any device on any network. Customers expect frictionless access to on-premises and cloud apps from any device, anywhere and at any time.

Modern authentication system must have intelligence to understand the context and risks and determine authentication processes accordingly. Modern authentication system must provide a low cost, scalable solution, giving users the access they need and the seamless, on-demand service they expect.

Foot Note:

OAuth 2.0
OAuth 2.0 is the industry-leading standard for enabling access to APIs. Simply put, OAuth 2.0 is a standard framework that allows an application to securely access resources on behalf of users without requiring their passwords. This open authorization also lets the user understand what kinds of access and information the application is requesting, and then provide consent.

OpenID Connect 1.0
OpenID Connect adds an identity layer to OAuth 2.0 and simplifies existing federation specifications. It enables identity federation as well as delegated authorization and includes other capabilities to enhance dynamic interoperability.

SAML
Security Assertion Markup Language (SAML) is an open XML standard for exchanging authentication and authorization data between an identity provider and a service provider. SAML allows businesses to safely share identity information across domains. The process is often called federation.

FIDO
Fast Identity Online (FIDO) defines a set of technology-agnostic specifications for strong authentication. FIDO was designed to reduce reliance on hard-to-remember passwords to authenticate users and address the lack of interoperability among strong authentication devices.

Why Workload Automation is critical in Modern Data Centers

Today, all CIOs demand that their data centers be able to mange dynamic workloads and have the ability to scale up or scale down dynamically based on their workloads. The demands of digital transformation of various business process implies that the entire IT services stack must be built for "Everything-As-A-Service." And this needs to be intelligent, self-learning and self healing IT system.

The always ON paradigm of the digital era brings in its own set of IT challenges. Today, IT systems are expected to:

Manage all incoming data. Data from a wide variety of sources and formats must be imported, normalized, sorted and managed for business applications. The volume of incoming data can vary greatly - but the systems must be able to handle it. IT systems must accommodate a wide variety of large scale data sources and formats, including Big Data technologies and integration with legacy in-house and third-party applications.

• Enable Business Apps to sequence data, run data analysis and generate reports on demand. On demand workloads makes it difficult to predict future workloads on IT systems - but the systems must be able to handle it.
  
• Ensure all Business Apps adhere to the published SLA.

This expectation on IT systems places a tremendous pressure to automate the management of all IT resources. As a result CIOs want:

1. All workloads are effectively spread across n-tier architectures, across heterogeneous compute resources and across global data center networks.
   
2. Predictively detect IT infrastructure failures, Automatically remediated failed/disrupted processes and workflows in near real time.
   
3. Intelligently predict future work loads to automatically apply policies about when and where data can reside and how processes can be executed.

The traditional IT workload management solutions relied on time based scheduling to move data and integrate workloads. This is no longer sustainable as it takes too much time and delays in responses to the modern business needs. 

As a result, we need an intelligent workload automation system which can not only automate the workload management, but also made intelligent policy based decisions on how to manage business work loads.

Today, the IT industry has responded by developing plethora of automation tools such as Puppet, Chef, Ansible etc. Initially these were designed to simplify IT operations and automate IT operations - mainly support rapid application upgrades and deployments driven by the adoption of DevOps strategies.  

However, these tools have to be integrated with deep learning or machine learning systems to:

1. Respond dynamically to unpredictable, on-demand changes in human-to-machine and machine-to-machine interactions.
   
2. Anticipate, predict, and accommodate support for fluctuating workload requirements while maintaining business service-level agreements (SLAs)
   
3. Reduce overall cost of operations by enabling IT generalists to take full advantage of sophisticated workload management capabilities via easy-to-use self-service interfaces, templates, and design tools.

Over the next few years, we will see a large number of automation tools that can collectively address the needs of legacy IT systems (such as ERM, Databases, Business collaboration tools: Emails, fileshare, unified communications, and  eCommerce, Webservices) and 3rd platform Business Apps - mainly entered around IoT, Big-Data, Media streaming & Mobile platforms. 

Current digital transformation of the global economy is driving all business operations and services to become more digitized, mobile, and Interactive. This leads to increasing complexity of everyday transactions - which translates to complex workflows and application architectures. For example - a single online taxi booking transactions will involve multiple queries to GIS systems, transactions and data exchanges across several legacy & modern systems.

To succeed in this demanding environment, one needs an intelligent, scalable and a flexible IT workload automation solutions. 
  

A Three-Step Product Commercialization

Launching a new product is one of the most of the core activities a product manager must do. Launching a product is both costly and risky for any business, and that’s why specialists – called as product managers are brought in.

In order to take a product idea into a successful product, there are several stages of development. Customer requirement, use cases and value to customers has to be identified – and often this is the easy part. Then comes the tougher part – how to commercialize the product. 

Launching a new software product has become very complex. The notion of what denotes a ‘product’ and what denotes a ‘service’ is getting rapidly blurred. In addition, the commercial & monetary aspect of software is incredibly complex. The options run from pay-per-use models or annual license fee or one time license fee or even freeware.

The complexity of pricing and commercialization can make anyone go crazy. 

In this article, I will go over a simplified 3 step plan for product commercialization. Going through this will help you identify and access the business risk & help develop better plans.

Step-1: Create a purchase process map

Step-2: Get a Beta Customer

Step-3: Analyze all sales deals.

Pricing of the software has major impacts on several aspects of productization: Packaging, Distribution, After-sales support, marketing and lifecycle planning. It is therefore very important to incorporate the product commercialization plan right at product design stage. (See: Building World Class Products)

1. Create a purchase process map

As part of product design, one needs to think on how any customer will buy this product. I call it as a purchase-process-map which details every aspect of the buying process. Product Purchase-process-map is a very powerful tool that will help gain deeper insights on what the customer really wants to buy and how you can develop a product around it.

Start with customer research that provides great insight into customers' needs and identifies the factors that motivates customer to buy. Once customer motives are known, you can develop a sales & marketing strategy for the product. 

The first step in developing a purchase-process-map is to get an answer to “WHO” questions:

·        Who orders the product?

·        Who inventories the product?

·        Who will use the product?

·        Who influences the decision to buy?

·        Who controls the budget?

·        Who will dispose of the product?

Learning about all the players who have influence over the purchase is very important. When selling complex enterprise products, companies use dedicated Account managers or Account teams whose main focus is to work out the customer purchase maps and then sell products. So, when developing new products, it will be good to have representatives from sales or account teams who understand customers. 

The purchase-process map must be as accurate as possible and it explains the customer buyer-behavior. Do not make the mistake of assuming that you know the buying patterns of customers based on similar products purchased by customers. Always base your product purchase map on facts and not assumptions.

For example, a software company did a voice of customer research and identified a need for unified data center resource management software. However, the purchase-process map revealed that there were no real users of this product as customer operations were still distributed with servers, network and storage being managed by separate teams and no single team or member was looking at the entire data center infrastructure. Identifying this problem helped to avoid developing a new product. Instead, the company was able to cobble up different software tools and offer it as suite. This learning saved several millions of dollars in development costs and at least one year of development time. 

2. Get a beta customer commitment

Traditionally, beta customers are used for product testing. But Beta customers are also very useful in developing financial aspects of the product. It is best to co-develop a product with a real customer and they can provide valuable feedback on the financial aspects of the purchase process.

In many cases, Beta customers expect a big discount on the purchase price, they can provide inputs on various monetization schemes such as:

1.    Paying for using the unit – one time license fee.

2.    Paying for annual license fee including support

3.    Paying for installation of the product

4.    Software is free, but customer pays for support.

5.    Software is free, but is supported by advertisements

6.    Software is free, but developer can collect & use customer data

Beta customers can also help in product marketing & sales by:

·        Agreeing to give written analysis of the product

·        Agreeing to endorse the product

I have worked on several new product development projects with customer and in most cases, customer was very much interested in developing a monetization model for the product. In one instance, customer helped develop the product and also defined the product cost.   

3. Analyze all sales deals  

Initial sales of the new product must be analyzed against the purchase-process-map. For every item in in the purchase-process-map, there must be a corresponding sales or marketing activity. The review verifies whether each of the sales and marketing strategy actually delivers. This also helps to identify weak links in the marketing program that needs to be corrected. 

Analyzing sales deals is very important for new products. Failing to address key customer needs can impede the product adoption process. Identifying issues early in product launch will help keep up sales momentum.

Remember that if sales efforts stalls, and sales reduce, distributors and sales team will simply turn their attention to other products. Sales team will not analyze why the product is not selling. Once the momentum is lost, it is much harder and more costly to get the new product back on track. To ensure success, review all initial sales deals and periodically review deals to identify any roadblocks that could jeopardize the new product introduction.

Closing Thoughts

The stakes are high with every new product introduction. The company reputation and product manager’s reputation is on the line. The best way to see a product’s success is to follow this three step process and incorporate this into product launch plan and sales strategy.    

Remember addressing product issues early on and eliminating product adaption barriers, you will be setting up the path for success and build products with a healthy revenue stream.

Use this 3 step plan for product commercialization. Going through this will help you identify and access the business risk & help develop better plans.

Step-1: Create a purchase process map

Step-2: Get a Beta Customer

Step-3: Analyze all sales deals.

Remember addressing product issues early on and eliminating product adaption barriers, you will be setting up the path for success and build products with a healthy revenue stream.