Developing a great product takes time and a lot of patience. 

Much like Rome, the product that you absolutely love, too, wasn’t built in a day. It takes months (sometimes years) for product developers to arrive at an idea that innovates on technology, solves user problems, and is just the thing the market had been waiting for. 

Founders take us through their journey on product iterations to understand how they pushed through failures to create our favorite software.

Alan Kay (the famous American computer scientist) has this famous quote, and it is written on our office walls, that is our core guiding principle on UX, which says, “Simple things should be simple and complex things should be possible.”

When you are building a product, you should remember that when somebody starts using your product, it should look very simple.

They should get hooked on it, but as they dig deeper, they should be able to do a lot more complex and sophisticated things.

It’s like peeling an onion, and as you go deeper, layers of features start coming out of the product but on the face of it, it is not intimidating.

This is the core design principle and the core product philosophy around KISS (Keep It Simple, Stupid). 

The KISS philosophy is rooted in this approach of keeping things very simple, but they have the possibility of achieving complex things.

This way people don’t abandon our product after some time because they keep discovering more and more ways to use it.

That’s the core tenet on which Kissflow is built and represented by our “Power of Simple” brand value.

We have a natural intuition around product capabilities because at the end of the day we are the users of the product, we can see and feel those challenges and I think we have that advantage which I know many founders and teams out there don’t have.

That helps a lot from an intuition perspective to say that this makes sense, we need this now, we need this three months later, we don’t need this at all, and that depth helps there to be where we were sometimes able to push the customer and say that what is the real problem you are trying to solve.

We have a company value that we call “problem first, solution second”.

What that means is we don’t take feature requests from customers or users, we take problem requests instead.

In fact, we never go to our product team with a feature request, we only go to them with a problem.

So that puts the onus on us as a go-to-market team to make sure that we go really deep into the problem. Then we take those problems to the product team because we are a very product- and engineering-focused company.

This way, you can think of the ideal way of solving the problem and not of something an individual user or customer has asked you to. That has helped. As a B2B company, we focus on three things: pipeline, requests, and prioritization.

We use a lot of data internally and try to group requests, map it by pipeline stage map, map it by road map and compare value versus time. 

Honestly, it is still more of intuition than a clearly defined way. I don’t think there is a clear framework, but we try and bring all of this data together before making any decision.

When you have seven to ten years under your belt doing one thing, it is easy to get distracted and to start exploring areas that have nothing to do with your core product.

In the Pune office, we tried to build new products which had nothing to do with our core product, and pretty soon we realized that it was not the right approach for two reasons.

One, because there is so much opportunity in our core product that focusing there allows for much better use of bandwidth rather than doing something completely new.

Two, if you are indeed doing something completely new, you become on par with everyone, elsewhere you are not taking advantage of the capability, skills, knowledge, and brand that you have built over the last 10 years.

So, since we came to this realization, in the last two years or so we have become super focused on perfecting what we already have rather than getting distracted in doing something else.

We ended up building a product for our own restaurant. Early on, this was definitely not a business idea. We were genuinely trying to solve our own problem.

Given that we had invested in the restaurant, we decided not to shut it down, but to see it through and learn from it instead. That was the pursuit, that was the idea. But then, the universe conspired.

I ended up exiting my telecom company. Sakshi was also kind of done with services.

We both were talking about cracking one thing together and in this period we also gathered a few excellent, outstanding individuals who were working for our respective companies, who we felt could crack something bigger and greater if we all could come together.

And there was POSist because we could clearly see that we were solving a problem at restaurants which other restaurateurs were talking about.

We gathered our first ten customers when we did not even have a company name.

The gap in our team was the product management experience.

Being a software engineer by training, having previously worked with Fortune 500 customers for close to nine years, and having worked as developers throughout, we understood code, but none of us had project management experience. 

And we did not appreciate the importance of product management as a discipline—for one person to wear that hat and make decisions around the product. It was very important to have a product counterpart for the go-to-market person designing things for GTM.

Instead, as engineers, everybody doubled down on building the product, assuming that we knew the product.

If you think about Freshworks, the product manager has so much go-to-market savviness that the product already rakes in many things.

This gap was, in fact, one of the main reasons why we took longer to establish a product market. It is very important that amongst the founding team somebody wears the hat of product manager.

That person should take the call to guide everybody else. Otherwise, the engineer takes over the execution. We think we can solve everything through code, and we keep on building more features, which is what happened with our team.