Quitting On A Client

Startups journeys are kaleidoscopic. Every piece of the journey veils a part of the big picture and unveils some. The startup team can either be aligned in this idea of fragmented reality or believe in their make-believe team spirit and some day be trampled by the incoming train.

I recently had to quit on a client. In India, and for a small business, quitting on a client is probably rare. Yet I had to do it.

I had given many strong hard thoughts to it and every iteration brought me back to the same answer. Quit.

We are into product design. We shape a founder’s ideas into a product. And this is a tricky ground. Many founders come with such a strong business background, it is difficult to convince them they know nothing about product design.

More so, about the one’s who have worked a large portion of their career in large corporates and dealt with vendors. They put up efforts to treat a product designer as an equal partner in thought, but never sincere enough. They tend to revert back to their behaviour with vendors while on job.

Now, product design by nature, requires you to tell your client how to do things. And they’d rather tell you how it should it be done (because of money, skin in the game and other cultural reasons).

This is further complicated when founders want to focus on ‘business’ and delegate tech to the tech leprechaun.

 Third, there is total dissonance on what it costs to build a product. So while the founder makes discoveries in the market and pilots a changing product to surf the wave, the tech cofounder is expected to cope up with constant changes without putting relevant capital or thought (time) on the table.

And when you add a career finance person to the team (bean counter) who knows nothing about technology, tech crowd and original context we have someone trying hard to bring down input costs in line with manufacturing industry or vendor suppliers.

Soon, as a equity partner in the game, its your skin in their game.

Only way this unequal relationship can be normalised is when people who make mistakes end up paying for them. Directly and without any cover. And when it comes to making those choices, the real tech founder’s character is revealed. The others have to learn that they are in on the gold rush, only if they get the ‘tech’ mindset.

For Prodio therefore, it was back to basics — Stay loyal to the product and not client, and when there no scope of that, rather quit on a client than the product.

Various Principles On Decision Trees in Stock Trading

A trader has to take many decisions and over a period of time he develops wisdoms, principles, strategies, trade plans and actions them out. This is an attempt to layout a structure.

A wisdom is a fully defined decision tree

A wisdom is a decision tree of principles
a principle is a decision tree by itself
When principle meets data decision is derived
A decision is a product of a decision tree
A decision tree is a product of a decision
My actions are my revealed preferences
my revealed preferences are my decision trees
Sometimes i learn new behaviours , those are decision trees I added to me

A strategy is a decision tree with environmental inputs defined- either as constraints or as incoming datapoint.

Choice has a basis or a reason.

Reasons are deterministic datapoints.

All sets of choices during a transaction I can make defines a decision tree.

A trading plan is a defined decision tree for a strategy.

Where ever there is an option, there is a decision tree.

A sample transaction decision tree

Chosen Instrument is a given starting point. A state of environmental variables is a given — CMP, OI, Order Book, values of various indicators, capital, allocation, bucket positions etc.

Buy-Sell is a choice.

Buy — new entry or exit , if exit — partial or full

Sell — new entry or exit , if exit — partial or full

 

Then trading terminal offers MIS/NRML , Market/Limit/SL/SL-M , Day/IOC, Regular/BO/CO/AMO. The user makes choices along this transactional decision tree. Every choice made from a group is every other choice not made.

Price & Quantity are also choices, which we’ll currently not include in the decision tree for simplicity sake.

Event: The event that happens post which one branch of the bayesian tree is irrevocably chosen. e.g. The buy transaction based on above choices.

Outcome: Let us for simplicity sake tie up value of a decision tree to a single quantifiable outcome and see various values for this outcome over a defined time frame. e.g. over next 1 hour, next 4 hours, today, this week, this month, matching with usual trading timeframes. Outcome starts after event occurrence. The outcome is calculated for the branch actually taken.

Alternate Outcomes: The outcomes calculated for each unique branch of the tree that could possibly have been taken.

At various timeframes, the value of outcome and alternate outcomes are compared. At various timeframes, there could be the chosen path or any one of the alternate path that has a better pay-off. These values form the basis of further analysis.


Consider a sample case for answering should I put market order or limit order while trading in cash/F&O segment, which decision is better.

At the timestamp of such a trade being executed- there is environmental data like order book, LTP, and subsequent tick data that allows one to build

X = entry price at limit order since subsequently LTP ticks show whether the limit order would have been executed or not and after how long.

Y = market order that results in picking off best bids

A difference between X & Y indicates cost of market order. Consistent positive difference indicates amount of overcharge due to market order and used to calculated probability and show recommended trade as limit order in case of option market , as I’ve discovered.

Consider another case: should i trade intraday or carry my trades?

Often intraday traders receive margin financing versus carry trades that require providing for full margin. This leads to smaller trades.

I would like to answer if I was better off trading intraday and larger sizes or trade smaller with larger capital can carry the trades. What is the impact on my IRR.

With outcome payoff calculated over various time frames, we can find the difference or multiple between intraday versus day of closing event profits/losses to arrive a ratio of intraday versus carry trade profits and if the ratio is smaller than what i would have gained using margin through intraday trade- an alternate trade recommendation would suggest trade type intraday & trade quantity as larger quantity as a decision path with higher payoff.

Source: www.medium.com

The Switch

At Prodio, we have quarterly goals of lifting our development process up to next level based on pre-defined roadmap. That roadmap is not very clear, but pretty good in it’s approximation, and by the time we arrive there, we’re clear.

I call this The Switch. Once it is down, the inevitable consequence of it follow for the whole organisation. We fondly and regularly flip this switch. A new one is coming.

Recently chanced upon an article on Netflix Techblog and ended up overlapping it with out thought process to see if we’re in right direction. Seems we’re. So this is a little comparison of what we do that they do followed by what we intend to do next.

Where we are similar: We have teams dedicated around products and see their work as building and delivering products.

The portion of this philosophy that we need to cover next are:

  • The developers must participate in product definition and design process

They must be able to place the value of Epic-Feature-Requirement relationship and why a particular requirement is prioritised for delivery currently. For a given requirement they should be able to define the persona and user journey and list the value expected off that journey. They must be able to link this to UX patterns and choose a given UX pattern to achieve the objective. They must be able to check the UX/UI for logicality/Consistency/Contradiction test and should be able to write all test cases comprehensively to reduce future iterations.

  • The developers must participate in architecting process

The developers should be able to evaluate for a given new requirement the relationship with the underlying data model and architecture diagram and introduce definitions & test cases for backend required and check for impact.

  • The developers must be able to anticipate disruptions and look out pre-emptively

Library upgrades, OS upgrades, appstore policy changes, third party integrations bringing changes etc must be converted into a tangible framework for staying on top of potential changes


Where Netflix has created ‘centralized teams’ , our idea is to create an ‘engineering’ team. This team takes care of:

  • Infrastructure architecting & management
  • Monitoring
  • Tools
  • Design, architecture and patterns
  • Feedback & training

The brief of this team is to prepare a visibility map for upcoming product developments and laser sharp focus on accumulation of any Tech Debt in our portfolio. We’re setting uptill June’19 to convert these into tangible measurable processes.

Source: www.medium.com

Upon Axiomatic Thinking

As we walked in semi lit lanes of our tree covered area in this winter evening, the pleasure of clients turning friends started peeling layers upon layers.

The man is at the starting point of many bayesian forked forest of his entrepreneurial journey and pondering on some deep questions. The choices he makes will be a revelation of his character under formation, but which will leave closed the alternate paths not taken. He needs a friend to navigate.

Men who have travelled ahead, each offer him their preferences. Those in turn revealing their character.

But my advice is:

You must at any points carry your own certain Axiomatic Truths to navigate these decision trees. These may be few. But often having just one , renders rest of the carefully arranged thinking superfluous . A decision is often derived from the axiom you hold dear.

I offered him three of mine:

  1. A successful product is a densely packed bundle of logical value proposition for a user. Mixing value propositions of other stake holders may kill it.
  2. Any product must aim for monopolisation of its ecosystem by relentless market fit feedback to product development roadmap
  3. The capital that comes with no terms and no horizon surrenders it’s entire optionality to the product, leading to best environment for axiom 1 being fulfilled in a startups life. So that capital is good for product

Source: www.medium.com

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