Trying to ask the right questions

About 15 months ago, I started building an application. Or rather, I started building an application framework, before deciding that the framework was a vanity project and I should just focus on the application itself.

It wasn’t a particularly exciting proposition. I just wanted to build a simple accounting product as a personal development exercise. I wanted to learn more about the process of innovation and application design; while I had a lot of technical experience in building products, I had had relatively few chances to help direct them.

I chose an accounting application because it was something simple, practical and where I felt I could identify a feature that was missing from other products on the market. The feature in question was the ability for me, as a UK banking customer, to import and categorise transactions efficiently from my online bank statement. There were existing products with direct online banking integrations (e.g. Mint), but these only appeared to work with banks in the US. For British customers, the best I could find was the CSV upload feature in Toshl, which I found cumbersome to navigate. I wanted something more intelligent and which involved fewer clicks.

I initially made good progress, but as I approached a stable MVP (Minimum Viable Product), I encountered two problems:

  1. I had become uncertain that it really was an MVP – or, to put it another way, I began to wonder if I had built the wrong features.
  2. I had less and less time to work on it – halfway through the project I moved from a stable and relatively comfortable agency position to a fun but chaotic startup where I had real responsibility, and I found that my new job demanded a lot more of my time and mental energy.

Ultimately, the project stalled completely for a few months, leaving me to answer the question – ‘what now’?

Asking the right questions

Despite my first few months at Movebubble being an exhausting experience, they have also been incredibly fun and rewarding. I’ve learned more about product delivery in that time than I did in over a year of working on my own initiative.

Being there has also pushed me to invest more time in reading and studying the theory, and that in turn has given me a new perspective on how to progress my own work. In particular, I’ve gained a different kind of understanding as to what really constitutes an MVP and what an MVP is really for. I feel I have a better handle on the kind of questions that I need to be asking if I am going to be making the product even slightly successful.

When I first started development, I focussed on building what I considered to be the smallest set of functionality required for people to want to sign up and regularly return to my application. But my process for deciding what those features were was arbitrary – it was based entirely on what I considered to be an MVP.

Yet I am not my customers. I understood this, but wrongly concluded that to understand those customers better I needed to deliver something relatively polished and mature in order to get useful information about what it was that they really wanted. I understood that an MVP should be the minimum amount of functionality required to get people to engage with and use my application.

But really, when you have constrained resources and a number of unanswered critical business questions, an MVP should be the minimum amount of function required for you to at least partially answer one of those questions.

If I had a large pot of time and/or money and I was close to 100% confident that people would buy my product once it was finished, then the most efficient use of those resources would probably be just to go ahead and build the product.

But as an individual developer working a few hours a week with relatively small amounts of cash available to invest – it would be pretty disheartening, if not a complete disaster (I still have a full time job, after all), to spend two further years building something only to discover that nobody wanted it.

So I should be approaching the problem from a different angle and thinking I can learn faster and smarter, reduce the amount of wasted work and increase my own confidence that what I’m doing is on the right track.

Time for a change of tack.

Initial hypotheses

My initial supposition – that there was a gap in the market for an accounting application with smoother integration for transaction import – might seem fairly clear at first glance, but in itself poses a couple of difficult questions.

Firstly, what do I mean by an ‘accounting application’? Why would people want to import details of their personal finances into a web app in the first place?

Some reasons I can think of:

  • To get a clearer picture of how much they are spending in different areas, in order to identify ways they could save.
  • To track spending against existing budgets, to improve their day to day decision making.
  • To help them work out how much they can afford to spend on a one-off purchase, perhaps a car or a wedding or a holiday.
  • To make financial decisions related to mortgages and investments base on projections of future long term income and expenditure.

Most of these really boil down to the same thing – visualising and cataloguing spending in order to help decision making. But what if there are others? And how do users want to interact with the information once it is there? These are questions I can’t answer by myself.

Secondly, what exactly is ‘smoother integration’? I’ve had a number of adhoc conversations about this over the last year and have encountered a number of different opinions. One person suggested that they would want direct integration with their account because they were too lazy to maintain it themselves if it needed more than a few clicks. But another said that she liked having to input transactions one by one on her phone because it enforced discipline. Other opinions varied along this spectrum.

While this seems to demonstrate that there is room on the market for a number of different approaches, it would also be wrong to assume that people always know what they want and blindly trust what they tell me. So how smooth does the integration need to be in order for people to want to use it?

Thirdly, for there to be space on the market for such an application requires that there is nothing else already out there that already does the things that I propose. Since it’s not yet clear what features I am proposing (or rather, while I think I have a pretty good idea, I have yet to confirm that these features are the right ones) it’s hard to answer that question conclusively. But as part of any approach to delivery I should have a good understanding of what else is already out there.

So when I break down my initial assumption, I come out with three questions I think need answering:

  1. What do consumers want out of an accounting application?
  2. Do users find the process of importing transactions to be painful in existing applications?
  3. What can be done to make this process less painful?

I may think of more, but for now this seems like a good start.

Getting the right answers

Note that none of these questions even begin to address technical or platform issues such as whether a web application (rather than e.g. a mobile app) is the right medium for this. At this point, I’m merely trying to identify what rather than how.

Or rather, the first how that I need to answer is not how do I build a product to solve these problems? but how to I go about answering these questions in order to identify the problems? 

That’s a harder question than it might first appear. It would be quite easy to assume that I could just ask people but, as already observed, people rarely know exactly what they want. Opinions and qualitative feedback are certainly valuable components of any research of this kind, but I also need a way of demonstrating and quantifying my conclusions.

For example, I could try advertising a given set of features and see how many people sign up to be notified of future developments. Or I could try advertising on different keywords and see what my click through rate is.

There are a lot of different ways in which I could approach this but the key limiting factor is going to be time. Given that I have a limited amount of personal time and money to invest, what approach is going to give me the most useful amount of information for relatively small investment of effort?

It’s not a question I’m ready to answer just yet; but it does feel like the right question to be asking.



Leave a Reply

Your email address will not be published. Required fields are marked *