The art of achieving perfection

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

– Antoine de Saint-Exupery

The story of Maven is a journey towards perfection.

What started as common sense, slowly evolved into a way of doing things – the Artha Shastra way. The ad-hoc, piece meal approach gave way to a structured and systematic approach to problem-solving. This was step one of removing the cruft and starting on the path to perfection.

However, this methodology that was still so complex that people paid good money and spent valuable time to try and understand it. Here was the next step, to remove the complexity by using machines to do what they are good at and let humans use their intelligence to guide the machines towards the larger goal. Thus began the journey of Maven development.

The third step of simplification was to present non-linear, non-intuitive effects, which arguably mimic the butterfly effect, to appear simple and linear, more like the domino effect. Lots of late nights with the UX experts finally helped us achieve the same.

The fourth step was the development, or rather the lack of it. The discussion of what would remain in the product and what would be left out. It was more than a quest for a minimum viable product; it was to reduce the overall complexity of the product while being useful for a large set of use cases.

And we are currently in the final stages of achieving perfection. How do we communicate the benefits of Maven is a clear and concise manner. We can speak volumes about the goodness of Maven, but as always, perfection lies in taking away until there is nothing left to take away. And we are getting closer with every deleted word and rewritten sentence.

Stay tuned to know more about Maven and how it can help you achieve perfection in your service delivery.

Entrepreneurship Technology

How to build the unimaginable?

Get started…

Those were my thoughts when I took up the challenge of building Maven (then known as Project Andromeda).

There were so many reasons not to do it, unfinished and continuously evolving specs, unknown complexity, several dependencies, no development team in place, no clear target user, unproven market, extremely aggressive deadlines, fear of running out of money etc. But there was one important reason to do it: it hasn’t been done before.

Having decided that I want to do it, how do I go about it?

Well there is only one way to build software, to start building it. It cannot be done by sitting on the side-lines and waiting for things to fall into place before you begin. It needs a team to be built, need analysis, write specs, design, architect, code, test… and building Maven meant that we were doing all of these at once.

And then we celebrate…

The thrill of seeing the thoughts of several people in bytes and pixels is difficult to articulate. We know that we have just scratched the surface, and there is a ton of work to be done, but we also know that the journey ahead is much more manageable than what we have went through.

Why copy-cats don’t keep me up at night.

It takes a special type of environment to achieve something like this. You need people who are willing to suspend disbelief, embrace chaos, put their careers on the line and work with single minded focus to make it happen. Maven could not be built in an enterprise environment. It would take over 10 person-years to complete, and will be way behind what Maven would be by then. But to ensure that Maven is years ahead of competition, we cannot rest on what has been achieved and continue to innovate and create new benchmarks.



There are different stages of prototyping, which increase in fidelity and time taken to create. Therefore it is important to start with low fidelity tools and move further as the ideas are more concrete. Some of these tools are

  • Story-boarding
  • Creating Paper Prototypes
  • Digital Mock-ups
  • Wizard of Oz
  • Video Prototypes


This technique involves rough sketches which tell a story. It should have the stage (people, task being done), the script (actions, sequences of steps) and the outcome (fulfilled motivations, satisfaction). Since these are lowest fidelity tools, a harsh timelines, like 10min per storyboard, fells keep the focus and discovering various options.


Storyboarding helps in keeping the focus on the problem being solved, instead on the UI. Thus having a common understanding of the goal and avoiding bike-shedding.

Paper prototyping

Paper prototypes are mock-ups of the UI using paper, post-its, sketch pens, scissors and glue, and other materials depending on creativity.

This technique helps in discovery of a good UI, and all stakeholders can easily contribute.

Once a good UI is discovered using paper prototypes, we can move onto the next stage.

Digital Mock-ups

These are the digital version of the paper prototypes and can be created by a variety of tools like, Photoshop, balsamic or HTML.

These let you refine the UI before developing the actual application.

Wizard of Oz

This technique involves simulating what the machine will do using human operators. This is a very high fidelity prototype, where the users might think it is the real deal. But instead of coding the back-end, we only have the UI, while the back-end is powered by humans. This is especially useful if writing the back-end is an expensive task, like using machine learning etc.

Advantages of wizards

  • Places the user at the center of development
  • Faster and more iterative prototypes
  • Identifies bugs and problems with current design
  • Can envision challenging-to-build applications

Disadvantages of wizards

  • Simulations may simulate technologies that do not exist or really hard to build.

Video Prototypes

These can be thought of as the video depiction of the storyboard. Therefore it should also have the entire flow, including motivation and success. But instead of drawing, you show the user and the settings in a video.

However, videos, especially audio can be a huge time sink and so should be used appropriately and aim at telling the story instead of perfection.


How I hire writers

Now with the goodness of Hacker News and reddit. Thank you everyone for doing a great job proof reading the post.

Do checkout stackmonthly. A monthly roundup of best questions on

Good, creative writers are the backbone of our business. We try to hire and retain the best of them.

Our interview process is aimed to make the process efficient and objective. This ensures that we do not have to waste time in our hiring process and get back to real work ASAP. I outline the process below; in case someone else is interested.

Education Technology

HCI: Need Finding

It is the process of observing people to discover their needs, goals, and values. Although the course if about “Human Computer Interaction”, the process of need finding is relevant to developing new products or even new businesses.

A good starting point for any new product is to clearly identify an existing problem or need. That’s because finding a big problem and need often yields important untapped opportunities. Observing people also helps build empathy and think from their point of view. So, how do we observe people and identify their needs?

Participant Observation

Observe the users and their behavior in context (performing the activity). This is most useful when you want to see users in their element and learn about their experience.

While observing, we seek answers to these questions:

  1. What do people do now?
  2. What values and goals do people have?
  3. How are these particular activities embedded in a larger context, or the big picture?
  4. Similarities and differences across people
  5. …and other types of context, like time of day

While observing people, pay particular attention to any hacks or workarounds. These could be a gold mine for new ideas.


HCI: Evaluating designs

There are several methods to evaluate a design:

Usability studies

  • This could be informal, watch and learn or formal usability labs.
  • They offer good learning and uncover quirks, bugs or false assumtions.
  • it is not the same as user’s using it to perform real work in real environment
  • difficult to compare alternatives
  • experimental bias


  • quickly gets feedback from a large number of users
  • relatively easy to compare alternatives
  • No need to build prototype, a screenshot or mockup will do.
  • There is a difference between what people say they’ll do and what they actually do.

Focus groups

  • gather a small group of people to discuss a design or idea.
  • could be difficult due to group dynamics or if the subject makes people uncomfortable

Feedback from Experts

  • peer review
  • dogfooding
  • heuristic evaluation

Comparative experiments

  • taking two or more distinct options and comparing their performance to each other.
  • observe actual behaviour as opposed to self report (in surveys)
  • it can be better than usability studies since it compares multiple alternatives.
  • but you can’t observe people like in usability study.

Participant observation

  • observe people in their actual work environment


  • Useful when alternatives can be mathematically evaluated against design goals
  • Allows lots of alternatives to be compared


The method of evaluation to be used for the specific design goal depends on these (often conflicting) parameters:

  • Reliability: could be reproduce the results
  • Generalizability: applicability to larger set of people
  • žRealism: do the observations hold good in real world situations
  • Comparison: can we easily compare different (new of existing) designs
  • Work involved: the effort to get the feedback