Why Platform Business Model is Important Now More than Ever

Platform in general means “something that helps something else to happen”. And Digital Platform is no different. It is something that enables businesses to connect through technology and deliver value, for example, an e-commerce platform where producers and consumers interact with each other to create and deliver value. Sangeet Paul, author of the book Platform Revolution has defined a platform as “.... a plug and play business model that allows multiple participants (producers and consumers) to connect to it, interact with each other and create and exchange value”. 

If we go a little deeper into this definition we will understand that Platform allows a web of multiple channels to connect and perform core activities as opposed to just two entities connecting linearly in a traditional business model.

In the linear business model, there is usually one producer selling to consumers whereas a Platform allows multiple producers to utilize the platform capabilities and reach out to their consumers. For example, any seller can sell on Amazon, Spotify users have access to music from multiple artists and bands. These platforms are not restricted to one seller or one artist. This network of producers and consumers is what makes the Platform business model so different and disruptive. 

Let’s look at how this multi-dimensional Platform Business Model can help in the current environment where social distancing, remote learning, and telecommuting are the new normal. Since the outbreak of Covid-19, most of the countries are in major lockdowns, services like groceries and food delivery has seen a tremendous increase in demand. Early data in the UK has shown around 11% increase in the revenue of online food delivery compared to the same period last year. There was a record increase in the number of downloads of grocery delivery apps like Instacart, Walmart, and Target in the month of March. Almost every school and university is moving to distance or remote learning to keep their students and staff safe and avoid the spread of the virus. Given this surge in the usage of online services, customers would want more and more options available online. Customers would like to search, explore compare, and choose between different options within a single and uninterrupted user experience. Providing such an experience would be difficult and almost impossible by Linear Models and hence, the Platform Model will and should become the new normal. 

In my opinion, retail and education are the two industries in the B2C market that will be impacted the most and need to pivot to the Platform first approach in the coming days. Let’s look at them in detail:

1. Retail: 

We have already witnessed huge disruption in the retail industry in the last decade or so where larger brick and mortar retailers are struggling to survive. And now with the global pandemic impacting the day to day life and social distancing becoming the new norm, it will be even harder to get customers to malls or physical stores. Even after the lockdowns are over it will take some time to build customer confidence in revisiting the malls. When customers cannot visit malls, businesses should offer them a similar experience digitally, multiple sellers selling under one umbrella, exactly what Amazon has done. Amazon digitized the concept of the traditional marketplace which put them in a huge competitive advantage. The same concept now should be extended to other types of retail, like fashion, real estate, etc. Imagine a platform where designers can create their own boutiques and provide personalized services to their customers and customers can chat with stylists, try outfits from various designers in virtual trial rooms and accessorize their looks. Now, instead of each designer building, these capabilities which can be expensive and inefficient a platform can expose these capabilities, and designers can create their own digital experiences using those capabilities which will be faster and risk-free. 

2. Education: 

Education is one industry where digital innovation is long overdue. There are very few schools that are equipped with digitized content let alone running an entire virtual classroom. After the outbreak of the pandemic and lockdowns, many schools moved to virtual classrooms using Zoom or Webex but those are just stopgaps. Teachers are spending days before the sessions to create the digitized content and prep to fit the lessons in a virtual setting. We are in desperate need of a Platform that can allow institutes to set up their virtual classrooms for each grade, upload curriculum, create digitized lessons for each class, and conduct online exams. Such a Platform will not just be useful for schools but also for students and parents where students can form study groups, parents can chat with other parents, etc.

Virtual classrooms are not a replacement for the actual classrooms but if we have such a platform available then any school can create a digital experience using the platform capabilities as and when required. And capabilities like school administration will always be useful for process efficiency without any impact on the quality of education.

The above two industries are on top of my list which will need to adapt to the new normal quickly and Platform thinking can help them achieve it. But there are definitely other industries and sectors in B2C and B2B markets that will be impacted and need to pivot to a similar Platform first approach to embrace the new normal and stay ahead in the curve. 

Product Manager in an agile world

In traditional world, for an idea to translate to a product, it had to go through different phases like conceptualization, solutioning and then development. Market research team would do the research, come up with a concept and hand it over to the product manager. Product manager would then come up with a solution and pass the requirements to project manager. Project manager would then get the development started from the team. In this scenario the vision of the product or the business objective gets diluted like a Chinese Whisper game. There is no single owner in this case. Market research team is responsible for the concept, product management is responsible for the solution and development team owns the development. But no one is responsible for creating a sustainable quality product as a whole. 

How can this problem be solved? There must be one person who owns the product, who is responsible for the product from concept to launch. Now, who that person should be? Who other than Product Manager can take that responsibility? As he is the one who is close to the market and closer to the development team. For successful delivery of any product, Product Manager must closely work with the development team. In agile world, Product Manager is part of the development team and works closely with the scrum master.

What an agile product manager must do: -

1. Be part of the development team: - Product Manger must not work in isolation. He or she should be part of the development team like developers, QAs, etc. Product Manager must work very closely with the scrum master through the iteration or sprint. Product Manger knows the business priority and Scrum Master knows how the team is progressing, they both can help each other in critical decisions. Scrum Master and Product Manger roles complement each other throughout the product life cycle.

2. Participate in sprint meetings: - Product Manager must participate in all the meetings, like iteration planning, daily scrums or stand ups, retrospectives, etc. as he or she is part of the scrum team. In fact he or she should drive some of the meetings like iteration planning. Product Manger's inputs in these meetings are very important. For instance if there is a change in priority from business, product manger is the one who would know it first and this input in daily stand up or iteration planning meeting will help the team to start accommodating such change early on, instead of last minute surprise.

3. Work with market research and other stakeholders: - Being part of the development team doesn't mean that Product Manager should not participate in market research, concept triages and brainstorming sessions. As he or she is closely working with the development team, his inputs about the feasibility and the limitations of accommodating and implementing new ideas are very vital. Knowing these details early in the cycle helps in faster decision making process. 

4. Think like an end user: - Product Manager must always think that the product is developed for himself. What features and functionalities he would want if he has to use the product. Product is of no use if it cannot satisfy end users' needs. Hence, while building a product, Product Manager should always put himself in end users' shoes and take decisions.

What an agile product manager must not do: -

1. Work as a separate entity: - Some Product Mangers work remotely, away from the development team. This creates a huge gap between the team and the Product Manger. Product vision is not translated to the team. The communication cycle for the smallest information becomes very lengthy. When Product Manager works in isolation, he is not aware of how product is evolving and team is unaware of the long term objective of the product. Hence, adaptability and agility of the product becomes very low.

2. Responsibility without authority: - Product Manger should have complete authority on the decisions regarding the product. A pseudo owner without any authority may lead to team burn-outs.  Since Product Manager is responsible for delivering a successful product, he should be authorized to take important decisions about the product. Involvement of other stake holders is important in decision making process but Product Manager should be the one who makes the final decision. 

3. Unsustainable pace: - Don't bite off more than you can chew. Many Product Managers make a mistake of signing up a lot for the sprint and rushing the team through it. It might be possible to achieve this in one sprint but it won't be sustainable. Team would get worn out and slow down which would impact the velocity in long run. Product Manager must ensure that team has enough work that can be delivered without being over worked.

4. Release everything at once: - It is always advisable to test the water by dipping your toes rather than jumping in the pool. Hence, never target to make a big bang release with loads of features and functionality. Start small, release few features, gather user feedback and work upon them. Always test the market by releasing an MVP with few but important features, collect user reactions on the existing and missing features and build the road map based on that. Product evolving from user feedback is much more sustainable than a product released with lots features and functionalities without taking any user input.

Product Vision: - 

Product Manager should envision the product right from start. He should be very clear on what the product is supposed to do and what it is not supposed to do. End goal of the product must be well defined and communicated to everyone. For example, for a loyalty platform the goal of the product should be to simplify points collection and redemption mechanism. Product Manager must have this vision in mind and must bring everyone onboard with this. Sharing the vision with everyone involved is very important, business stakeholders must know what are they marketing about and development team must be aware on what should be the final outcome.  

Product vision must be brief and broad. Product Vision must not include granularity and details. There must be enough room for creativity. Hence, it is important that Product Manager shares a broad and unified vision of the product with everyone involved.

Backlog Grooming: -

Once the MVP is identified, features or requirements outside the MVP goes into Product Backlog. Product Manager is the owner of that backlog and it is his responsibility to keep grooming that backlog along with the development team and other stakeholders. New items must be added to the backlog and existing items must be modified or removed depending on the product evolvement. Product Backlog must be dynamic and must adapt to user feedback, market reaction, technical changes, etc. It is also important to prioritize the backlog regularly. A high priority item in the backlog may become low priority few months after the release and a non existing item may get highest priority. Hence, it is important to make appropriate changes to the product backlog from time to time. Some teams like prioritizing the backlog for every iteration, some do it every release.

In conclusion, product manager in an agile world is like a glue that sticks together everyone involved in the product development. He has a clear vision of the product that he communicates to everyone. But he also accommodates needs of the business and development team. He works closely with business stakeholders, yet he is part of the development team

                                     

Project Vs. Product

Service companies often find it hard to instill product thinking in teams. People working on software applications believe that they are only on a temporary project - that could range from a few months to a year. When it’s done, they can move on to other projects. The application is seldom treated as a 'product', that needs to live in production for many years after the project is completed.

We’ve worked with a large online travel company for over seven years now. We’ve seen both long and short term projects. In fact, at one time, our team of 100 people were working with a client’s in-house development team of 50 people! This experience taught us many lessons and I’d like to share my experience in this post.

Our application architecture was such that it had 3 web components for different channels and around 20 services (6 of them being major ones). We had 8 features teams across two locations making changes to these web components and services. Each new feature development was termed as a “project”. Usually, a project would span across multiple services and couple of web components. Every team was working on different web components and services in order to meet the requirements. Each team had its own style of design and coding and hence there was no consistency in the code.  It was a nightmare to maintain a codebase with 150 people checking in code simultaneously.

Reality struck when our client decided to reduce the ThoughtWorks team size and increase their own capacity. Ordinarily, this would be a routine knowledge transfer phase. But given the size of our codebase, it proved to be quite challenging. An exhaustive knowledge transfer required us to change our own mindsets - we had to stop thinking of teams being part of projects and start thinking of them as being owners of products.

Every service and web component was a product now. We had 5 teams owning these products. Code check-ins in each product repository was restricted only to the owner teams. This brought in lot of confusion at the beginning, because almost every project (feature) needed changes in multiple repositories by multiple teams. This increased the feature rollout time but improved the code quality and consistency.

We identified teams to own services and web components. We transferred knowledge for 6 major services and 2 web components among 4 different teams at the client end. We retained a web component with our team. This way, we didn’t have to transfer knowledge of everything to everyone - but only transfer targeted knowledge to relevant teams taking ownership. By now, each product had its independent repository and owning team.

Changing our mindset from being project aligned to being product aligned transformed the way we did the knowledge transfer. But apart from this, there were many long term benefits, to name a few:-

1. No dependencies between services: Previously, all the services were in a common repo, which created dependencies for compiling and building code. A single check-in in one of the services would build each and every service. Build failure because of an issue in one service would block everything. Separating out services in their own repos made the compilation and the build process independent
2. Ownership and responsibility:  After the ownership transfer, teams became more responsible towards their respective products. Any defect arising in a product was the responsibility of the owning team. As a result, teams became more watchful and aware of their products
3. Code consistency and Quality: Product quality became the primary focus of all the teams. Products were owned by just one team hence there was code and design consistency across the product.  It became easier to maintain smaller products as opposed to a monolithic codebase
4. Long-term product vision: Teams now were more focused and had a long-term vision. They started building their product backlog and working towards it. Their thought process changed completely. People were now thinking on how to improve their product in terms of modularity, re-usability, scalability, etc.

We learnt quite a few things as we moved on. Here are some of our learnings:-

1. Building an early backlog:  When we started as product teams, we did not have backlogs for each product. We did normal feature development but across different product teams as opposed to developing it in one team. But this mindset began to change and we began building backlogs for every product
2. Assigning a product owner:  As we realized that creating a product backlog is important, we also felt the need to have a product owner for each product. Hence we assigned a product owner to each product who worked very closely with the team in creating the backlog and working towards it
3. Treating web channels as customers: Our products consisted of web components and services. Web components were the channels through which end users can interact and buy tickets. It was easy to build the backlog for the web components, but for services we were not as sure. We then realized that as web channels have end users as their customers, web channels should act as a customer for services. Hence we started building services backlog by taking requirements from web channels

Changing our way of thinking had a huge impact on us.  We were now thinking and talking about products that can be maintained easily, which have less or no production defects, technical enhancements in the products, etc.

One very important change we observed was reduction of tech debts. Earlier, a team working on one project would get done with that feature without removing or sometimes building on top of the existing tech debt. But now, teams did not move ahead with feature development without removing the tech debts, and building on new tech debt was out of question. Our teams’ behavior changed from “everyone is responsible but no one is accountable” to “take ownership and be accountable”.

User Experience --- A low hanging fruit.

When it comes to increasing sales and generating more revenue for a business, first thing people think is offering new products and competitive services. Online business is no different, when people talk about generating more revenue the immediate reaction is, what more can we offer to our users. But no one thinks or talks about improving user experience to generate more business. I had the same opinion till very recent but I realized that enhancing user experience can generate more revenue for your online business by improving the conversion rate and hence leading to more sales.

As I mentioned, I had never thought that improving user experience would lead to more sales. I knew user experience is important. Bad user experience frustrates the users and would lead to bad publicity of the website which would impact business indirectly to some extent. But now I know that enhancing user experience can directly impact the business and bring in more revenue.

I was working on a website which retails UK train tickets. It is the largest online train ticket retailing website in UK with good hold of market share and better understanding of the business. When talking about the enhancements on this website, selling add ons, offering faster and better delivery services, etc. were the features which were picked up for development most of the time as they had potential to get more business.

It is an open website where people can search and browse train timetable and tickets. But to buy the tickets on this website users have to mandatorily register or log in to the website (if already registered). In several analysis reports, it was noticed that there was a significant drop on the number of visitors on the website after the log in page. It was quite evident that the users find this process of registering themselves on the website tedious. Moreover it was not the one time effort of registration but users have to log in next time onwards when they come to the website. For this they must remember their passwords or go through the forgot password flow of resetting password through email, etc.

Hence, we introduced the feature of guest checkout, where users can only provide their email address and proceed with the booking without registration. If they are already registered and do not remember their password they can still proceed as a guest by only giving their email address. Login and registration were still an option to get extra benefits of saved preferences, etc. but was not mandatory.

This helped users in 2 ways they do not have to go through the additional step of registration and if they have once registered they don’t have to remember which email id did they register with and of course the password remembering pain was gone. When user is in hurry and wants to quickly make a booking for a train with a very close departure time, this was an awesome feature. Along with this there is a human psych of not wanting to provide many details to the online world where only providing email address can get the work done, and hence this feature became helpful.

After a week this feature went live, the drop of website visits after the login page reduced significantly. The conversion rate of number of people visiting the website and actually buying the tickets increased by certain %.  This was a direct impact of better user experience on sales and revenue. And hence I learned the value and importance of enhancing user experience.

We always focus on complex things to improve business and increase sales but really never care about such minor stuff, which can create greater impacts. User experience is one such thing, which can bring in so much value but is ignored by everyone. For example, an online retailer can offer all the jazzy products on the website at a lower price compared to the competitors but it is of no use if the product search of the website is pathetic. Users will not find those awesome products in the search and will not even know that these products exist at such low prices. Hence, making the search simple and relevant is the most important feature on such websites.

User experience is a low hanging fruit that can create larger business impacts yet can be tackled easily and quickly.