Questions, Troubling Questions, Helpful Questions.

Asking questions is good, even tough questions.

Particularly in the product ideation phase.

Sorry, that is true for any phase.

 

Engineers are trained for building. Building something new.

Building something new excites them.

Very much a human trait.

More the passion for building, more the excitement.

Actually, it could excite anybody. Almost anybody.

 

Almost?

Yes. Almost.

There are few who do not get excited by building alone.

They understand that the act of building is a vehicle, and nothing more than a vehicle to achieve the end objective.

Job title of these people does not matter; their thinking does.

And they know the end objective very clearly.

They may not know it intuitively, or through an epiphany.

They know the end objective through homework.

 

They do their homework because they do not want to build for passion alone.

They understand very well that passion is a great fuel.

They also understand fuel needs a compass.

They want to build SO THAT they can achieve their end objective.

(Remember that “so that”? It appears again and again in some template. Maybe in that template of User Story or something like that). Anyway.

 

They also understand that building a profitable product is riddled with many unknowns, countless risks, and sometimes just plain happy hypotheses.

They also understand that building costs money and time.

And they are not willing to burn cash and spend time on unvalidated happy hypotheses.

 

So, they ask questions.

Often tough questions  

They question prospective customers, stakeholders, and most importantly they ask themselves to validate their happy hypotheses.

Does that remove risks?  Not entirely.

Does that remove unknowns? Not entirely.

Does that bring them to a realistic platform? Certainly, to a great extent.

 

And since they know their end objective (Not always, but most often it is MMM, Make More Money), they ask questions like these (and surely many more) …

- Is there any void in the market which we can fill?

- Who else has already built something like this?

- Will somebody pay for this?

- Will enough people pay for this so that we MMM?

- What is a problem worth solving, and what is merely polishing the bonnet?

- How much will it cost us to break even?

- What must be built in the shortest runway?

 

Answering these questions requires a laser-sharp outward focus.

At times it can be demoralizing, but it is revealing.

Those who treat Product Building as a vehicle to achieve the end objective, generally ask these questions before they start the cash burn.

Because it can save serious cash.

And more importantly it can save a team from burning out.

Poor outcome burns out a team faster than hard work.

 

A tough question can hurt.

An unasked question can cost a truckload of cash and leave a team demoralized.

Open-Heart Surgery on a Monitoring System

 Two Days, One Fault, and a 12-Bed ICU Monitoring System.

< 
This is *NOT* a “4 lessons I learned from blah blah blah” kind of post. 
This is a plain story. There is no world-shattering wisdom here.
If you find a takeaway, it is at your own risk.
/>

At 2 AM on an empty road in Ahmedabad, I was walking back from a hospital with a brand-new 12-bed ICU monitoring system that refused to work.

I had just completed my B.Sc. in Physics and Electronic Instrumentation. Within days, I landed my first job—and I was thrilled. It was with a renowned company in medical instrumentation, number one in ECG machines, DC defibrillators, ICU monitoring systems, and more.

They took me in as a Service Engineer. My job: repair those machines. Chip-level debugging and repairs. Using an oscilloscope to study the circuitry, figure out why an ECG machine wasn’t working, then with a soldering iron yank out the faulty chip, resistor, capacitor—whatever it was—and watch the machine come back to life. Fit to monitor a heart patient. That joy was beyond words. I wonder how many will even understand today what “chip-level” means. Anyway.

Because of this job, I got to know many surgeons and heart specialists. It was a very, very satisfying job. This story is about one day that turned out to be both my most frustrating and my most satisfying.

I was working in Mumbai when we received an order for a 12-bed centralized ICU monitoring system from a civil hospital in Ahmedabad. We had supplied many 4 and 8-bed systems—our standard models. This being a municipal hospital, their ICU was quite large. The 12-bed monitoring system was custom-designed, and I was looking forward to commissioning it.

 

Eventually, the big system reached the Ahmedabad hospital from Bangalore, and so did I from Mumbai. I carefully installed all 12 bedside monitors—smooth work.

Then came the centralized monitoring system, where a doctor is present round the clock.

The system had come brand new from the factory in Bangalore, polish still shining. It should have worked flawlessly. But the system disagreed. For two days I struggled with bed-to-system wiring. No luck.

At the end of the second day, I decided to open it up and start monitoring the monitoring system itself. Luckily, I had brought my beloved Tektronix oscilloscope, even though this was supposed to be a straightforward installation of a brand-new system. It was a dual-trace oscilloscope, with a 4-second memory—you could even freeze the scope to study a waveform closely. It was my prized possession, though it belonged to my company.

That oscilloscope was my eyes and ears. With it on my desk, I felt confident—the way a soccer player feels stepping onto the field in his favorite shoes.

Luckily, the Bangalore factory had sent me the circuit diagram. Because it was a custom-built system, they wanted to play safe. Armed with the diagram and the oscilloscope, I started my quiet conversation with the anatomy of that 12-bed monitoring system.

Around 11 at night, I saw a flicker of a problem. I say “flicker” because at first I wasn’t willing to believe my eyes—or my oscilloscope. One small capacitor (I’ve forgotten its µF value now) was shorted. Simply shorted. And that tiny fault was making the entire downstream circuit null and void.

Just a couple of weeks earlier, the entire system had been built in Bangalore. I’m sure it must have been tested. I say “I’m sure” because in that moment, I was extremely angry, blaming people in the Bangalore factory.

Today, I see that differently. A capacitor failing was simply a statistical event—a very unlikely one, perhaps, but still possible.

It was past 1 AM. I packed up the open-heart surgery I’d performed on my monitoring system. The nurses and doctors around me were curious to see the internals. They were considerate, too. At 2 AM, I started walking back to my hotel. 

The roads were completely empty. I was burning with anger inside, but I had a strong feeling that the problem had been located. Now it was just a matter of replacing that capacitor. The proof, of course, would come only after the replacement.

 

The next morning, I asked my taxi driver to take me to an electronics spare-parts shop. Luckily, he knew an area with hundreds of shops selling all kinds of electronic equipment, kits, and components. I bought the required capacitor. I still remember the shopkeeper telling me that I must buy a packet of 50 capacitors. So, I bought that packet of 50.

 

I knew in my heart that only one of these 50 would work the magic and bring that 12-bed ICU monitoring system to life. But if my diagnosis was wrong, all 50 would be useless.

Within an hour, I was back at the hospital. I walked into the ICU, plugged in my soldering iron, and replaced that capacitor.

 

And without any more fuss—like a class of 12 disciplined boys—the system started displaying 12 traces, exactly matching the 12 bedside monitors.

 

The joy, the satisfaction, the anger, the relief, the sense of achievement—it was all beyond words.

 

The nurses around me were happy to see me happy. “What was the problem?” they asked.

I showed them the faulty capacitor—about a quarter the size of a thumbnail.

They looked a bit puzzled.
Maybe they were wondering… all that two-day drama, just for this?

 

—No CPUs/GPUs were harmed in the writing of this blog—

User and Buyer Personas

As in any business, understanding user personas is crucial in software product development.
Even a multi-billion USD org does that carefully.

Understanding their pains & aspirations in their work life is of paramount importance.
Understanding the difference between User & Buyer personas is also important.
Maybe understanding pain & aspirations of Buyer personas is more important.
This homework can help you take your roadmap in the right direction and save a truckload of cash.

For any team, writing code & shipping features is exciting.
Too often, I see teams skip this homework in the excitement of shipping.
Soon, they discover that writing code is just a small part of the puzzle. 
Your team need not discover it again.

A brand new train and DoD

A brand new train and DoD

The brand-new train left CST station with a big fanfare.
It was scheduled to reach Delhi in 18 Hrs. It reached exactly in 17 Hrs 42 Mins. A grand welcome followed at Delhi station.
But on the 2^nd day, the newspapers wrote nasty stories about the inaugural train journey.  
First class passengers complained that AC was so cold that they almost froze to death.
The W/C in the second class had no water. What departed as a swanky, shining train, reached Delhi as a shitty-smelling train.
Out of 16 parcels to be loaded at Kalyan, only 14 were loaded.
Out of 8 parcels to be dropped at Jaipur, none were dropped, and all reached Delhi.

The railway minister was facing the ridicule of the press and the wrath of the PM.
At the same time, the GM of Western Railway was throwing a party to celebrate the maiden departure of the new train service.  
Train Loaders at Kalyan and Jaipur were telling their friends proudly about the new train.
Bogie attendants were telling their families how nice it was to be on the maiden journey.

In software building, ‘on time and on budget’ is like ‘reaching Delhi in 17 hours 42 minutes’, but means nothing if the experience stinks, flow is clunky, and integrations are broken.

Such things happen when teams are not mature.
A straightforward way to build mature teams is to establish clear DoD.
Teams will never mature if DoD is not enforced.
Teams will never mature if DoD is kept optional. 

Common Language and "A"gile

In the aviation industry, their terminology is universally agreed upon and universally understood. So, whether an Air France Pilot is landing in Warsaw or a Lufthansa Pilot is landing in Denver, the terminology used by the Pilot of Air France or Luftansa and the ATC at Warsaw or Denver is identical, and the language is the same, English.   

In the knowledge industry, where the raw material is nothing but ideas & thoughts, it is utmost important that communication is crisp and w/o any corruption. 

Why am I thinking about this today?
Because I have been seeing too many scholarly articles again and again for too many years on the same subjects like... 

- What is a User Story
- Can Testing Story be treated as a User Story
- Can we assign Story Points for a Bug
- Relation between Epic & User Story 
- DoD vs DoR
- Common misunderstandings about the role of a Scrum Master
- Confusion between Product Backlog & Sprint Backlog
- Whether Agile is a framework or a methodology or a mindset or yada yada yada.

Sometimes I think Agile WoW is no more Agile Ways of Working; it has become Agile Ways of Wording.

Can you imagine 2 people in *ANY OTHER FIELD* working for 20 years *WITHOUT*  having a common language and common understanding about the terms they use on a daily basis? 
‘A’gile professionals have managed that unbelievable feat. 

Identify Herbie in your team

Remember The Goal by Eliyahu Goldratt?
Remember Herbie and his overweight backpack?
No doubt Herbie had good intentions when he packed lots of canned food & iron skillet.
He must have thought that the canned food and skillet would help him on his hike. But that turned out to be the problem for him, and he turned out to be the bottleneck for his team.

Are you in the business of building software?
Are you shipping something valuable fast enough?
If yes, then congratulations. You have achieved something that thousands of teams strive for.

But if you are not, or if you strive for more, then maybe there is a Herbie in your team.
In your case, your Herbie will not be a person, but the canned food and the skillet will be taxing your team for sure.
In your case, the iron skillet will be in the form of pompous, nebulous, impressive, and weighty terminology.
In your case, the canned food will be in the form of canned processes & ceremonies, in the form of meetings with rigid structure, in the form of a warning that your processes are immutable, in the form of a waiting period for the next version of THE GUIDE, which allows you to change your thinking.
Maybe your Herbie is carrying tins of canned food, whereas a few energy bars would have worked better.

In The Goal, Alex Rogo took all the canned food and the skillet from Herbie and distributed them among all the boys.
In your case, you should simply discard it.

Of course, one should not go on a hike using just floaters.
If you want ultralight gear to help your endeavor of shipping something valuable fast enough, talk to me.
I have ultralight gear for you.
The same gear with which we built something, which is being used by dozens of Fortune500 Orgs.

Reminder to myself

I jotted down a few points that worked well for me and my teams while building SaaS products.  Though these learnings are from my context, I trust they are fairly generic. So, there is a very good chance that it could work well for you too.

Product Vision Canvas::  
This is the most crucial homework a Product Manager could do for Hypotheses Validation. I will do this carefully before 1st line of code is written because it can save me a trunk-load  of cash burnt.
 
Hypotheses ::
Hypotheses validation does not get over with Product Vision Canvas.  Every User Story is a hypotheses. And that is why it should be built Slive-by-Slice.
 
Unknowns::
Accept the fact that there would always be unknown variables.  My job is to reduce unknowns and reduce impact due to unknowns.
 
Bite small, Chew well::
Make vertical slices of User-Stories. Never deliver a US completely at 1st shot. Deliver small slices (but often). If I screw-up, at least I will screw-up less and make quick course correction.
 
Shift Left::
Cultivate shift-left mindset across the team. That will safeguard me from unpleasant surprises (well, mostly). Shift-left is not waterfall.
 
Prioritization::
RoI would be my only criteria for prioritizing work (barring requirements related to statutory/legal/patent/security/etc).
This means while prioritizing, I should have a fairly good idea about the "value" & "Cost" of the work I will undertake. 
 
BugFixes is not value addition::
I don't reward myself when I fix a bug.  Maybe I stop frowning at myself when I fix it.
 
Telemetry Code::
Track the Behaviour of Customers. It helps to get VoC. In fact, it provides a massive amount of feedback (just like VoC)  w/o asking a single Q to any Customer.
 
Infrastructure::
Defining coding style/Coding practice/Improving developer productivity/Improving security/Building automation/Infrastructure for CI/etc are more important than building features. (Repeat, *FAR MORE* important than building features.) Most talented/capable minds should handle this, rather than building features.  

Feedback::
Seeking market feedback on your previous release (and using that feedback) is more important than shipping the next release (Repeat *FAR MORE* important than shipping the next release).