Vendor Hat vs Product Manager Hat

My business often requires me to think on behalf of my clients. The germ of idea they’ve come up with, is often just that. A germ. It needs growing into an organism that will work, compete, grow and win. And there’s always capital constraint to build the ProductV1.0 of the idea. How do you define the right V1.0.

Many times you’re able to see a V1.0 that’s far larger than what the client thinks would suffice. If you accept client’s version, what sort of product designer are you – cause you’re not really thinking.

And, V1.0 is always in absence of proof from the market. It’s an hypothesis. If the client team is good enough to execute it correctly, then more information on product market fit will emerge during business operations. That will go into redefining the product. And that’s Product V2.0. Prodio has to continue to wear the product manager hat and track the product-market fit data and define ProductV2.0 on client’s behalf and execute this.

The vendor hat, on the contrary is quite limiting. Even if I believe your idea of V1.0 is grossly shallow and won’t take off, its none of my business. You loose your shirt, I gain some and the idea is forgotten. Almost every client we have has come to us after being hit by a vendor hat.

 

Marketplace Model vs Inventory Based Model

After a totally disastrous vacation, felt great returning to Mumbai. Sitting on my favorite wooden table, sweating off malarial fever, I’d a small discussion with a client. I thought it needed a note.

What should we build – an online market place for rented assets in a particular category or a platform to aggregate inventory and offer to customers?

Shallow analysis calls eComm portals as market models but I say it’s a closed integrated system customer is falling for. When buying –

  1. Customer needs price, product, substitute comparisons
  2. Transaction assurances – counter party guarantees, delivery time, returns, refunds etc

And the heart of buying is 2nd point- hence world got over eBay.

So, before a loose call to go for ‘asset light market model’ is taken, it’s important to understand what is at the heart of the problem you are solving. Most often it requires building integrated closed loop system to deliver that value – not just provide handshake with counter party. That time is gone.

Money Won’t Solve The Problem, Maths Will

All of us have heard of the Indian Foodtech meltdown & juicy stories of startup founder sieged by employees. And it’s some what fashionable to kick the investor’s teeth for being so stupid to throw all the money.

But trying to solve the same issue for a client who’s into deliveries on electric bikes, I formulated the problem somewhat differently.

What is the product that allows me to work with a team of ONE.

And, I think it’s this boundary condition for which product has to designed; at least in the imaginary story board.

If internet business are about creating new business categories where none existed earlier, and none existed because none was possible with that times technology or market, then why is the delivery problem still being solved with more people, capacity overhang, and traditional way of doing business where technology is just seen as enabler.

I believe when enough math is thrown at it, it’s possible to create a delivery business platform with dynamic routing algorithms & alignment of incentives where the ‘corporate’ team will be a team of 5. ceo, hr, ops, marketing & office boy.

And unless the delivery players operate on this razor’s edge, there’s no business to be created in delivery. We’re out to prove this with one of our client. We’ll share the results in time to come.

Extreme Programming & Product Design

I’ve never been involved with projects that are not short of something. Time, money, patience, wisdom something.. or everything, is always short.

The the thing that’s always short is – plan.

And designing products while business is being rolled out is the most significant challenge I’ve faced. Product design requires thoughfulness, business rollout requires relentless execution. And, over a period I’ve come to acquire a few ideas in product design from extreme programming.

XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements.

Same principle applies creates Extreme Product Design. End goals are fixed, but you’ve to reach there while meeting the market. A good product designs gives up more than it takes, but giving up while taking on clutter during business execution requires a methodical focus and product planning processes in place.

Flow Of Work

So, an org is working. In their silos — whether emails, cabins, phone extensions, buildings or continents.

But where is the org. It’s in its flow of work. As it happens. And for most layers, there’s no way to see the flow of work.

There is just abstraction of work through statistics that get reported in MIS. A lot lost in translation.

So what we do is insert a simplest layer on top with which the org emails & phones plug. Now whole org is on this layer, but everyone can see everyone, to the extent they want to be seen or shown.

And the fact of visibility creates responsibility.

Abstractions of Org Processes

When people come together to work, they organise it into processes. For a good collaboration product, the process creation should be extremely easy, accessible to multiple people and should able to merge based on best process that emerges.

A process has a creator, an owner, a responder, a flow, escalation points, open or close, enforceable or recommendatory, has data points to be collected at various points, each data point has to be collected through UI pattern & UI pattern should intuitively approximate user behaviour in offline world, psychologically.

This whole thing should be representable as a matrix. The matrix when loaded into the engine attaches organisational processes to the communication channel.

Activating bot, starts the monitoring & navigating help process for anybody who enters the product.


Merging

Multiple processes at times may have to be merged or made to mirror reference process. This process should be similar to Git. Its a git for organisational processes or data points.


Engine

The Zen of Productivity Product

Currently orgs use tools of the past. Business cycles have compressed, time windows to success have shortened. More has to be done with less in lesser time. Cognitive burden has increased. But orgs continue to use tools of the past, creating outward spiraling cognitive load. This causes friction & an org layer dedicated to friction removal.

Ideal is minimum viable org to meet the biz goal, and no more.

For this we see an org as org dynamics layer & underlying work layer. Org can be minimized by simplification of org dynamics to minimize cognitive load. The underlying work layer, specific to each industries & built on wisdom of last generation of technology, needs design thinking applied for simplification & minimization.

Org = Planning + Execution + Underlying Work Process + Actions

Planning = Direction+Judgements+Decisions+Tasks + Classification +Timeline +Accountability+Measurability+Visibility+Bottlenecks

Execution = Communication +Action+Escalations +Decisions

UWP = Input Trigger+Value Adding Actions

Actions = Defined flow of steps + Tackling unknown + Skill Development +Feedback To Process Definition.


UI Pattern To Relate To Human Actions

A human interacts with UI based on intuition & experience. Earlier enterprise applications created ‘work flow’ which a human was expected to follow through forms and controls.

We intend to transform the experience from forms to UI elements that related to user more intuitively. e.g. A simple checklist is intuitively understood as creation of work, its priority, its due date, creator as work giver and responder as doer of work, tick as sign of delivery, measure of finishing, visibility etc.

An untick by another user can be construed as supervisor’s disapproval of work done. A ticking cycle indicates how many iterations. The time between ticks indicates pace, clustering of ticks indicates using product as compliance rather than collaboration tool. Several behavioural patterns are hidden in micro data related with simple UI elements which can be used to identify & eliminate frictional behaviour. Ultimately topography of a product educates & aligns the user to the product’s intention.

What can be inferred by implication, should not be asked.


Session 3 — Bundle Ideas

Several ideas emerge from the discussion.

  1. Work flow systems that link work but ignore human behaviour vs flow of work, human centered process where platform senses the meaning through measurement.
  2. Build in 10% cost 60% value, rather than 100% cost & 100% value
  3. Organisational layer resides on underlying work processes, organizational dynamics is a protocol layer to be abstracted into the product.
  4. The topography of the product should align the behaviour of the user to the objective by intrinsic motives rather than enforce rules.
  5. Synchronised flow of work reduces cognitive overload
  6. Hygiene processes can be abstracted into automation with a lot of effectiveness.

About Prodio

Above excerpt is from session 3-Bundle Ideas & session 4- create framework of Prodio’s product design sessions. These immersive sessions aim to explore several layers of problem to arrive at a path to minimum viable product.