Advertisment

Software solutions: The market network approach

Good software solutions are easily maintainable, generalizable and scalable; early design decisions and choices greatly influence the solution

author-image
DQINDIA Online
New Update
Software

The industry has seen the emergence of Market networks, which combine the marketplace with SaaS, typically in a focused category – leveraging the presence of multiple user types on-boarded for the marketplace benefit to provide multiple use cases.

Advertisment

Technology has played 2 common types of use cases:

  1. Platforms, typically a web portal or a mobile app wherein different users discover, associate or transact with each other. The most common platforms are e-Commerce marketplaces - a seller and a buyer discover and transact with each other. Buyers get a set of curated choices and marketplace controlled experience, sellers get wider reach and new business.
  2. Products, wherein users or companies use the software for a specific use case independently of other users. Recent products have typically been hosted on cloud (SaaS).

There are various challenges encountered that anyone building a platform or a product for SMEs should answer.

Advertisment
  1. Identify the Problem: What is the problem being solved? And why? It could be digitizing an existing workflow – and using the digitized data to make the decision making better? If so – a single process or multiple?
  2. Product vs Platform. A software product has easier and clearer use semantics and data ownership and works well when usage by a user is independent of others. Platforms derive their value from the strength of the users, but also bring up concerns about data ownership and security amongst users.
  3. Horizontal vs Vertical. It’s hard to provide multiple use cases across different domains. Multiple use cases require deep domain expertise (known as “the unfair advantage” in SaaS) and best delivered in a single domain.
  4. App vs Browser vs Desktop. Mobile internet users globally far exceed Desktop users. Except for enterprise solutions, the mobile version is important. Business use cases are repetitive, require notifications and engagement triggers, and are better suited as a mobile app.
  5. Multiple use cases. Multiple use cases can make the software complex and hard to use. They are justifiable if they add up, and help in adoption and create a lot more value for the users. Will the users come for one use case, and stay around for another? Does the data from one use case serve as the starting point of the next? What is the first point of entry in the market – and what are the metrics to say that the entry point use case is sorted? The next use case can even seemingly look like a different product/app to the users – before cross leveraging happens.
  6. First user communication should focus on a single value proposition, which may be different for user types. Other features can come in as smaller bullet points or be more targeted once the user is on the platform.
  7. Metrics. Each use case may have different metrics, and an entrepreneur may be tempted to chase each of them competing with the larger companies in that use case. Instead, have 1-2 or core metrics, which take most of the resources – if the product is done right, the other metrics should grow organically from these.
  8. Data security. Platforms inherently create user interactions, while software products capture existing offline user interactions – both hence may have different data security expectations. A market network combines both use cases and hence must address data security concerns use case-wise.

User Experience

SMEs are like B2C customers – their adoption is largely digital, the individual users usually self-installed and trained. User interface design should have thought through clear 1st use case and user persona. What may be obvious to a founder or a product lead due to their prior deep immersion is often not to the user.

Advertisment
  1. User studies. Entrepreneurs have an irrational bias towards their approach to the solution. Early user testing challenges entrepreneurs with perspectives they may have missed. Early releases, feedback and iterations help achieve product-market fit quickly.
  2. Reuse standard components. Some UI components and UX flows have become standard. For example, if your software has eCommerce checkout, reuse the standard eCommerce icons and flows.
  3. Instrument app. In-app or web instrumentation tools such as Appsflyer, Clevertap, Firebase and Google Analytics help create, track and intervene at various stages of user journeys, and if used well – deliver more value than the investment into them.

Key Technology Decisions

Good software solutions are easily maintainable, generalizable and scalable. Early design decisions and choices greatly influence the solution.

  1. Right framework. Frameworks, built with the right software design patterns, are available in most major languages, server-side or frontend (browser/app). They have reusable plug and play modules/extensions for common use cases, scale well, enforce good quality and less code, and are easier to maintain.
  2. Build vs Reuse. Engineers tend to underestimate the effort to write software. Softwares are never static or one time developed, and tend to grow/evolve with the product and use cases. Understand what’s core to an organization and must be written from scratch, and what are essentially existing software or services should be plugged in. CRM, Support desk, Order management, Shopping carts, ERPs, text search and filtering, even Machine Learning recommendations are now standard services that can be integrated within an app.
  3. Modules and Interfaces. Clearly thought through modules, data storage entities/database schema, interfaces and APIs lead to easily maintainable and scalable software. Standard guidelines exist for each of these. The software architect should know all the potential use cases to design data storage entities/database schema that generalizes. This means, say, provisioning for a transaction or relationship type attributes in certain tables to allow other types that later newer use cases may bring up.

By Arvind Saraf, Founder and CEO, Wishbook

Advertisment