Sunday, June 25, 2017

The One Metric

In a conversation today, I said the biggest plus of YC SS was the weekly office hours, which got one to focus back on whats important. But as I was reflecting it over now, I realized that the first thing YC SS did was to make you identify the one metric that needs to grow.

This simple step in itself is so important. Identifying this will drive what questions you ask users, what information you seek out of them. Basically, it will drive the direction which the iterations of ur product take. Overtime, as you learn from users, either of 2 things happen. You realise that you are measuring the wrong metric or your metric should start improving.


While I am building Trici primarily for developers, many have noted that it can be useful for other use cases as well.The beauty of the one metric is that whatever the use case, it still accurately indicates the health of your product.

Tuesday, June 20, 2017

Convenience and Choices

Convenience plays a big part in choices we make. Given a choice, one would by default choose something that is more convenient/cheaper etc. This should make choices simple and it does in so many cases. But as we know that is not always the case. Sometimes bad choices disguise themselves with convenience and we make a mistake and learn. The tricky part is when you have two seemingly good choices. On the surface one seems obviously better than the other and while there is a voice in your head which is still unsure, you make the choice that seems better. As time passes, the voice in your head grows a little louder. You obviously made the right choice so why is the voice in your head still there.
This is because the seemingly good choice seemed better only because of convenience. In fact, if you remove the element of convenience, what seemed like a good choice may not even seem like a choice anymore because that is not what you really wanted. This becomes even more interesting because it is not always clear what you really want. Which is why advertising is such a big industry. When you see something everyday, it gets programmed as a want in your head.
If there is a voice in your head it is worth thinking why its there.

Thursday, June 15, 2017

Trici You Beauty!

I am using Materialize CSS library for my product. Just now, I was doing some minor changes to the UI of the product when I noticed that some of the styling was not working as documented on Materialize site. I then came to the conclusion that this was because I had not updated my Materialize css build to the latest one, so I decided to go ahead and update.

I downloaded the SASS build of Materialize which I would then customise as per my requirements. Over the last year, I have customised the css as and when needed, but realized in December that I need to have a custom SASS build rather than just a customised css file. So I had downloaded the SASS build of materialize and then incorporated all the changes I had done over the months in css to Sass by going through the diff of changes, git commit history etc. This took some time but now I had a customised Sass build.

I checked this in a separate repo and used it to build a new dist folder with the customised css, js and fonts. And henceforth any changes needed were made to the Sass files, a new dist created and then that dist used in the actual react app. This was fine till today when I noticed that I need to upgrade the Sass library itself. This meant I would have to and do all the changes to Sass that I had done earlier in December.

With a sprained neck, and a fucked up sleep cycle, I was totally not in the mood to do these again. There is so much work left to do, and the realisation that I have to do all of that alone really made me wonder what am I doing with my life. Is what I am building even useful? Usage of the product has been going south for many of the initial users. There are some positive signs but when you are demoralised, glimmers of hope are not sufficient.

With this state of mind, I made myself some tea and sat down to do the changes, pushing myself to keep moving. If only there were a tool which would make this easy for me. And then I opened Trici and searched through the Focus Sessions for December 23, the day I had initially made the changes to Sass files. It turned out I actually had a Focus Session where I had captured what changes I had done on the Sass files. I had searched earlier but must have missed this one. Suddenly, what seemed to be something that would take time was achievable in a matter of minutes. I knew exactly where and what changes to do .

And then, the demoralised me was all of a sudden upbeat. Just when I was doubting whether Trici was useful, its utility presented itself to me.

I don't know whether Trici will go onto be a successful business, but I am sure that it will definitely make lives of developers much easier. And thus, I am going to open it beyond the small set of private beta users. 

Monday, January 16, 2017

Debate the doubters

I am at a friends place right now. He also happens to be a beta user of Trici, the product I am building. He was explaining to me why my product would not work. He talked about the alternatives people could use. This was a good discussion. As the discussion progressed, I was able to convey to him why I thought that people would switch from the alternatives to using Trici.

When the discussion started I was not so sure footed. His arguments and points made me think. I did not come up with anything new. But I analysed my hypothesis against the arguments presented. And after a lengthy discussion came to the conclusion that the hypothesis still holds. Its yet to be proven though.

But this discussion reinforced my belief that Trici is solving a pain point. It motivated me to work faster to prove my hypothesis. 

Saturday, January 14, 2017

Getting back to writing

I have to admit, I have lost my skill to write. Tweets I can write, but long form... That is another story altogether. Someone suggested that I should write on Medium. I have to admit, I like the interface of medium better than that of blogger. But after the recent post by Evan Williams announcing firings at Medium and getting their focus back on figuring out a business model that does not involve advertising, I felt I should just stick to blogger. Blogger is not going to go away. 

If you think what I am writing is shit... Yes, well I am out of practise. But to get back to practise, I will have to start writing something.. Even if that something is shit. I hope to be more regular on this blog.  

Thursday, July 7, 2016

What happens when you ship something you are embarrassed of?

You must be knowing the famous quote from Reid Hoffman:


(pic credit: startupquote)

What happens when you ship something embarrassing? The fact that you are embarrassed means that you have an idea about what it will take for the product to be not embarrassing. Fix these edge cases, polish that UI etc. But when you put an embarrassing product in the hands of someone, your list of embarrassments gets prioritized.

And then you know precisely in which order to tackle the embarrassments. 

Tuesday, June 28, 2016

Sharpening the Axe!

One of the biggest dilemmas that every team starting up from scratch faces, do you invest time on things which are not getting you any learning about the problem that you are trying to solve and what the customer thinks. Over the past few months, time and again I have come face to face with this dilemma. Today, I was pondering over the choices I made and whether there was any consistency in choices. In retrospect, there have been a few mistakes, but there have been some good decisions as well.

Mistake #1: UI/CSS Framework

When I started work, my choice of CSS framework was Bootstrap. It was something I was familiar with, had good documentation and was used widely. If I would get stuck somewhere, the probability of finding an answer on stackoverflow or elsewhere was higher since so many people use bootstrap.
Instead of customizing it from scratch, I could use a freely available and customizable template. This is exactly what I did in the beginning and used the same bootstrap template in the desktop app as well as the landing page of the website.

This was a choice I should've stuck to. However, I came across a situation where I was looking for a particular UI component in react and did not find a good one which was using bootstrap (Looking back, I feel the perception of what was good was flawed.) Material UI seemed to be the rage, but in my quest to be different,  I ended up trying WinJS.react and Winstrap. This is an example of one of those classic mistakes which one makes when working alone. This was so obviously a bad choice, yet somehow I made it. Its not that I had to redo a lot of stuff. I wasn't very far in my project and the time I lost due to this was probably less than a week. But that IS A LOT OF TIME! In the end, when I came across Materialize.css I chose that and have been happy with my choice. Material design guidelines on color etc mean that my app does not look completely amateur from the design perspective.  But I do feel that sticking with bootstrap, I would have been able to get the app in the hands of the first five users quicker.

Mistake #2: Not resolving Webpack issues

Webpack is quite awesome! But to get a feel of all its awesomeness there is a learning curve. The reason I wanted to use webpack was because in my code I was using all these bleeding edge Ecmascript features which are still TC39 proposals, e.g. async/await, import etc. Thanks to Babel, this is possible. However, there way people have suggested to use Babel in Electron is to let the transpiling happen at runtime using babel-register. I continued with this approach because it resolved the errors I was getting. However, this meant that even for the most simple css change in one of my react components, I had to rerun the whole electron app.  The time taken for the app to start itself was getting larger, due to all the runtime transpiling happening every time.  What I wanted was Hot-Module-Replacement to save on the time which I was losing every time that I ran the app. Also, transpiling during runtime would make the MVP too slow on startup and was not giving the feel of a native app.

I tried integrating webpack and failed due to an error which I could not resolve nor could I find a solution on the internet. Worried that this was delaying getting the app into the hands of the first users, I let that branch of code remain and continued work on other features. I got back to that branch and fixed the issues after a full 30 days. Today, I got hot-module-reload to work as well and I can see just how much time would have been saved if I had fixed the issues earlier.

Good decision #1: Integrating flow-type and refactoring code

I did end up spending a month or so refactoring the code to use flow-type and Immutable.js. However, as the code has gotten more complicated, the investment in implementing these technologies has paid of by time saved catching bugs/errors which would have otherwise taken a lot more time to find and fix. At this stage, I have not implemented any automated testing, as that seems overkill for the MVP. But I will get to those very soon.

So the last few months have been a mix. I do sometimes get criticism that I have not followed the philosophy of "The Lean Startup", something which I myself advocate fiercely to others. My explanation for this has been that I am solving a pain point which I have. There is a minimum that I expect from my app before I give it out to other to try. Perhaps my perception of that minimum is biased, and I could have gone more minimal and learnt first hand from users. But from time to time, I have shown the progress to some of the first five users and the response has been positive. By positive, I do not mean, "Oh you are doing good", but "Oh I want that" Real feedback will only come once the app is in their hands.

I was speaking to an ex-teammate who, along with a few other ex-teammates, is working on his own startup. He was narrating how they have slowed their initial sales push because they need time to incorporate all the learning from their initial customers into their product.

I expect a tremendous amount of learning once I get the app in the hands of the initial users. Once all that feedback starts to come in, I will have to move fast. The time invested in setting up things like webpack-hot-reload or flow will pay off by allowing me to move at a faster pace when needed.

The key takeaway thought which I had today was something which I have had for years now. Invest time in sharpening the axe.