Design Challenge : Financing

 

                                                           By Jiaygang

Prodio is developing a product that makes it easy for a healthcare provider to structure a treatment plan as a pitch deck, communicate using that as a collateral, track analytics to see prospective patient response, enable ‘booking’ the treatment pretty much like a holiday package, get one shot itinerary of multiple phases and sessions under each phase planned for that procedure and being offered financing & payment options that reflect credit history of the person and yet allow the provider and patient a modularity through product UX that ensure minimum physical negotiation and maximises conversions from prospects to signup.

The specific UX/UI I’m trying to structure around Payment & Financing plan is :

I see payment plans are :
How much to be paid
When
How many parts
What frequency
Upfront versus on service

The financing plan on the other hand is:

– What is total payment of which which part is coming from where — client+insurance+financing

– What rate and when does it kick in
– how do you configure free interest period
– how the rate changes when your scheduled payment fails
– what penalties are imposed for failing payments
– when does a credit become delinquent settings

all of above should configurable settings.

Now the way i see is when you create a PROPOSAL

– it’ll be selection of a client
Treatment plan
associated payment plan
financing plan

That means there’ll be payment plan pre-configs — you could have 3 pre-configs created with different options set so when you are created a proposal the selection of pre-config payment plan automatically works our payment schedule and starts sending reminders etc accordingly.

Something along similar lines for financial pre-config that reflects the credit rating of the person.

THE ABOVE MODULARITY would be able to produce infinite combinations for the clinic so that if they don’t want to loose a prospect the will alter the terms or create another set of pre-configs based on experience knowing a category of patients.

Getting this right will enhance modularity and flexibility tremendously.

Keeping already developed UX/UI in mind, please provide the UX/UI for this portion.

*Modularity of financing and payment options and it’s consequences on rest of the product is an emphasis area

Source: www.medium.com

A product design challenge

A founder wants to build a group booking platform for dinning crowd. It will remove offline haggling to pre-structured discounts based on size of the group. The platform must know when the group booking done through the platform is consummated. The platform wants to capture relevant upside, in case group goes larger or consumes more than originally booked. The platform wants to form a float by collecting EMD for the intended spend as % of spend, upfront while booking. Eventual strategy of the platform is to build mechanisms to generate positive network externality. The platform also wants to ensure the user experience of choosing a venue & menu , while being online and non-app based , must reflect group dynamics the way this activity currently happens offline between friends.

As a product designer please frame the following:

Product purpose:

Problem:

  • Describe the pain
  • Frame how it is solved currently

Solution: frame proposed solution here

  • Describe how it solves the pain
  • Describe how exactly it connects the various personas
  • provide 2–3 use cases to support your case

Why now:

  • Describe historical evolution of the category
  • If your solution has never been created before, what recent change makes it possible now

Estimate Market Size: If possible estimate TAM (top down), SAM (Bottom up), SOM and give rational how.

Identify Competition:

  • List competitors and their competitive advantages
  • Identify what competitive advantage will you build to carve a place for this product

Frame personas and form market segments:

  • List all personas you see in the product and describe them
  • Identify the market segment closes to the personas and fix those personas as first round of customers

Design product by outlining key user journeys:

  • Describe the topology of the product you’ll create
  • Describe large broad values you’ll deliver and break them into feature sets
  • Describe non-negotiable user journeys and the experience
  • Relate and bundle the features as rollout strategy
  • Break into development version given 3–6–9 month time frame for development, deployment , going live

Source: www.medium.com

Ideas that have influenced me

Over time one gets clearer and deeper about choices one makes in professional life (and personal too). Last couple of years the going has been good and when I see myself doing well, I just wanted to understand what the hell was wrong with me a few years back — so much muddle?

From that emerged a need to look at my professional development as evolution of a bundle of ideas that shaped me and my thinking , the choices that I’ve made banking on them (or ignoring them and suffering for it) and provides now an amorphous framework of looking at decisions and designing products.

I’m taking a very close look at these to evolve a personal decision making framework — small to vast.

  • Startup = Growth
  • Strategy — Bruce Henderson
  • Network Externality
  • Game Theory
  • Polymorphism
  • Situational Awareness
  • Tipping Point
  • Sthitapragyata — Stoicism
  • Memetic Immunity or Vulnerability
  • Design Thinking
  • Not being stupid is smart enough
  • Seeing hidden options in everything
  • There is a Zen to poker (trading)
  • The invisible chess board
  • The maths of compounding
  • Designing for continuity
  • Beta players can make alpha teams
  • Extended phenotype
  • Samkhya Philosophy
  • 10X
  • The silence between musical notes, the pauses between words is a form of speech
  • Be alert to arrival of luck (bad luck) — from charlie munger
  • Theory of forms
  • Hollomorphic Singularity or whatever this is called — a point where many ideas, contexts and life experiences apart from inner states and accidents of memory and imagination converge to align and uncover a unique perception — inaccessible otherwise.

Bolotowsky — whose art i find representative of many ideas overlapping to produce a view.

Source: www.medium.com

How Prodio leveraged NodeJs async/await to modify Zerodha APIs — Part 1

We are building something that helps to manage risk, buckets your capital into meaningful allocations, automates your trade, and monitors your trading actions & decisions for retrospection and future trading decisions.

One of our core and challenging requirement is to process tick data which we receive from Zerodha which publishes tick data on websockets. Zerodha has provided a nice NodeJs SDK to save our coding efforts and simplified the whole process.

Our problem that Zerodha SDK doesn’t solve

Zerodha SDK provides an event “ticks”which can trigger a callback function passed to it on every received tick. By definition, we can receive multiple of ticks in a single second. But Zerodha SDK calls that callback function in a synchronous way which could block further execution of thread if we’ve to execute algorithms inside that callback function. This leads to missing ticks, if the post tick arrival processing — whether running some formulae or tracking for strategy — runs longer as number of instruments and number of formulae rise , the next tick will be missed.

e.g. One feature which required immediate solution was threshold tracking. In this feature, whenever price of an instrument crosses certain threshold of profit defined by subscriber in a limited time period (eg. if price of an instrument increases by 5% in 10 days), a notification should be sent to the subscriber.

So — we needed to convert zerodha node sdk into async mode, so we could set our processes running after the tick is recieved, while our main thread continues to listen for next tick. That allows us almost any amount of time for processing compared to earlier 500 ms thats generally there between Zerodha ticks.

//Sample code for logging frequency of tick data from zerodha using zerodha SDK


const KiteTicker = require("kiteconnect").KiteTicker;
const ticker = new KiteTicker({ 
    api_key: "api_key", 
    access_token: "access_token" 
});

ticker.connect();
ticker.on("ticks", onTicks);
ticker.on("connect", subscribe);
var start = process.hrtime();

function onTicks(tick) {
  elapsedTime("TICK RECEIVED IN:"); // first log may give incorrect result
  console.log("TICK DATA RECEIVED FOR INSTRUMENTS: ", tick.length);
}

function subscribe() {
 const items = [738561, ........];
 ticker.subscribe(items);
 ticker.setMode(ticker.modeFull, items);
}

function elapsedTime(note){
   const precision = 3;
   const elapsed = process.hrtime(start)[1] / 1000000;
   console.log(note + elapsed.toFixed(precision) + " ms");
   start = process.hrtime(); // reset the timer
}

//Tick data logs

TICK RECEIVED IN: 545.586 ms
TICK DATA RECEIVED FOR INSTRUMENTS: 60

TICK RECEIVED IN: 600.785 ms
TICK DATA RECEIVED FOR INSTRUMENTS: 75

TICK RECEIVED IN: 614.124 ms
TICK DATA RECEIVED FOR INSTRUMENTS: 60

TICK RECEIVED IN: 712.715 ms
TICK DATA RECEIVED FOR INSTRUMENTS: 43

TICK RECEIVED IN: 510.640 ms
TICK DATA RECEIVED FOR INSTRUMENTS: 29

TICK RECEIVED IN: 582.587 ms
TICK DATA RECEIVED FOR INSTRUMENTS: 36

TICK RECEIVED IN: 552.164 ms
TICK DATA RECEIVED FOR INSTRUMENTS: 52

What were our options:
1. Multithreaded programming language like golang, python.
2. Some way to make NodeJs more performant

Analysis:
1. Adding one more programming language in tech stack was not a viable option for us. Also, these programming languages had there own learning language which means developers had to spent more time in learning new language rather than solving important problems, implementing crucial features and contributing to the product.
So, we rejected this option.

2. We’d to figure some way to execute all algorithms parallely without blocking NodeJs event loop. So, we decided to solve this problem leveraging NodeJs’s async await feature. We wrapped the onTicksfunction with async op, this async keyword tells NodeJs to execute this operation or algorithm asynchronously without waiting or blocking next operation.

ticker.on("connect", subscribe);
ticker.on("ticks", 
    async (tick) => ( await onTicks(tick))
);

async function onTicks(tick) {
  // logic
}

In this onTicks function, we could split multiple operations like persisting ticks in db, executing algorithms, etc.

ticker.on("connect", subscribe);
ticker.on("ticks", 
    async (tick) => ( await onTicks(tick))
);

async function onTicks(ticks) {
  const ps = [saveTick(ticks), splitAndProcess(ticks)];
  await Promise.all(ps);
  return 'success';
}

async function saveTick(tick) {
 //send to sqs or REST API call
}

async function thresholdTrackingAlgo(tick) {
 // algo logic
}

async function splitAndProcess(ticks) {
  const executions = ticks.map(
    tick => thresholdTrackingAlgo(tick)
  );
  
  const results = await Promise.all(executions);
  return results;
}

Problem 2: Latency in network requests. We didn’t want to waste our precious time in network requests (for fetching tracked instruments current price, last traded price in previous tick, traded volume, volume traded in last 5 mins, etc.)

Options:
1. Blazing fast cache service like redis
2. In-memory caching

Analysis:
1. Redis comes with it’s own learning curve, which being a new technology for us could’ve taken more time for implementing the essential feature. New technology ( or service, tool, etc.) means more infrastructure burden, configuration, and management. Also, syncing tracking list & data between db and Redis.
Communicating with redis via network request would’ve introduced more delay, even though in multiple of milliseconds was a waste of available execution time.
So, we rejected this option for our use case.

2. Major advantage of in-memory caching was it brought down delay in the range of nanoseconds. It boosted I/O operations tremendously. There are already in-memory caching solution available on npm. We choose “node-cache” for it’s simple API’s.

Check this out : https://gist.github.com/jboner/2841832

Conclusion:

We decided to use NodeJs async/await feature along with in-memory caching which executes multiple and parallel processes like persisting ticks, executing strateg on ticks, stop loss monitoring, etc.

On the next article i.e Part 2, I will be adding a bit more to this by providing some results and analytics to show the execution time we saved before next tick arrives and some logging results.This part will also include more advanced use of async/await and running NodeJs in cluster mode across multiple CPU cores.

Note: If you need any clarification catch me as @pawan on prodio slack channel.

References:

  1. https://medium.com/@tkssharma/writing-neat-asynchronous-node-js-code-with-promises-async-await-fa8d8b0bcd7c
  2. https://blog.risingstack.com/mastering-async-await-in-nodejs/
  3. https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/
  4. https://medium.freecodecamp.org/what-exactly-is-node-js-ae36e97449f5
  5. https://www.andlil.com/en/tick-sizes-in-financial-markets-and-their-effect-on-trading/
  6. https://medium.com/@globalprimeforex/why-is-tick-volume-important-to-monitor-56a936eea70d

Source: www.medium.com

Prodio 2020

Bhojeshwara Shivalaya – if it had been completed , had a scope of ambition that would have made the grandest temple of Bharat look small. Ambition is life.

Its been a little over 3 years since we started. We’re at a point where ambition doesn’t defy logic.

I’ve been involved in various initiatives and a grand theme has started forming in my mind.

As a profitable SaaS portfolio strategy we are essentially moving towards turning into an incubator- because while we have ideas and execution , every product needs founders to run. So while we rummage through our store of internet wisdom acquired over time and new windows of opportunities emerging in the world to pick something to do- we need founders to carry those ideas to conclusion.

Some of the social ventures I’m promoting are part of this incubator – essentially only differing in the funding source. While the for-profit incubatees aim towards commercialisation, the for-societys-profit incubatees will move towards demonstrated success that leads to their crowd funding.

Hence Crowd Funding is our first product. There are so many around but our reason for building one of our own are very complicated, but real.

Thus un-named product is under conceptualisation stage right now.

 Source: www.medium.com

What Idea in 2018 changed your perspective?

I’d like to list some I felt this year and pick one.

  1. Alpha teams deliver more operational advantage at lower risk
  2. Loyalty to the user of the product you design ahead of the loyalty to customer or commerce
  3. Being smaller than your means opens the way to becoming bigger or another way of saying this — longitivtiy is a strategy by itself
  4. Strategy-Structure-Culture
  5. Ignoring is a proper response to a threat when means to neutralise it are available
  6. Children love big burly man playing with them
  7. Producing joy is important in every context for everyone
  8. 10X — looking ahead for the source of it in your life
  9. What to not do often decides greater progress than what you do
  10. There are non capital based sources of leverage — reputation, wisdom, network. Next big opportunities will walk in from these doors.

Though there is tough to choose for me which one impacted me most between 1, 8 & 10, but it is the 10th that has changed my way of going about in the world, the most.

Source: www.medium.com

Contours Of An Alpha Team

Had a difficult conversation to make with an employee, about not offering him the customary level jump to L3 inspite of 15 months.

As is my practice, i took him for a walk in pleasant winter evening in our sprawling industrial compound. And, as we took circuitous route, so did I take a long winding explanation. One on which i’ve been mulling for 3 months. But one which is based on First Principle I’ve formed now on this.

Our 2019 to 2020 end is transition into two areas of business- service & SaaS product portfolio.

Service, because it earns bread and butter at steady growth and allows us to develop tech stack, process and infrastructure but above all people.

And products, because that is where multiple revenue streams, annuities & J curves are. And fun too.

On service side we have been evolving on 3 fronts – productivity, development stack & processes.

Since essentially service business is fixed margin business that needs constant sales pipeline and no/low delays and failures and as much leverage of quickly reusable code libraries – we’re talking of a well chosen engineering stack and processes.

So what is well chosen about it?

The stack that allows relatively inexperienced devs to be highly effective in development. And agile processes combined with DevOps that take away release and infrastructure away from day to day developer. This should let them focus on delivery on application layer.

This is what I call delivery platform.

But no matter how great the delivery platform is , it is finally the people that have to deliver. And so what kind of people we have and how we sync them with our delivery platform matters a lot.

There are two groups here – the trainees and the pros. L1 to L3 are trainees. L4 to L6 are pros. L7 are commercial people.

What do you need in the trainee group – clarity & agency. Technical skills will take care of themselves as will our delivery platform.

What do we need in pros- potential to be a 10X dev.

That means nobody who doesn’t have the 10X potential steps into L4.

Does that mean we fire the people from L3 onwards- No, instead we offer fixed growth every year with job security. But how does that give one a chance to grow. We handle that with that every person based on project pipeline and requirement gets his personal challenge or sometimes 2–3 a year. Success or failure in that is a binary. And level specific. So an L2 gets his level challenge and L3 too. If you succeed you jump level . If you fail you get normal growth but surely get your challenges whenever chance presents. Untill you succeed or of course keep failing.

But success in challenges apart – agency & clarity is a must.

Because, that is the foundation of 10X potential.

This, coupled with rigidly sticking to a norm – each new hire should be better than last hired at that level or same level guy currently in office. And all freshers must give 6 months to product team before beginning as Devs , should get us into good shape.

Source: www.medium.com