One of the most challenging things about managing a startup is prioritizing and time management. I have to admit, I have struggled a lot with this in the past and still I am not perfect at this. Therefore lately, I have tried to go about doing all this in a much more methodical manner. How? by creating product plans to set the quarterly vision and use the Kano model to gauge customer satisfaction for new features. In this post, I will just talk about my approach to creating product plans, give an example of it before a deep dive into understanding and examples of Kano Model.
Running a small, somewhat poorly funded startup has been one of the most challenging things of my career so far. It’s not because any of the individual tasks are hard but I am juggling between so many disparate tasks and maintaining focus is a real issue sometimes. OK, before I give an example to help visualize what I am talking about, let’s talk a little bit about my startup.
My Day To-Do is my startup that I have been running for the last few years and something that has grown through the years. I am the founder and while there are no other full-time employees in the company, I have had “casual” help over the last few years. The involvement by others at the startup is strictly project based, e.g. an MBA grad to prepare a marketing strategy, a Chinese native marketing student to execute the China market strategy, designers to improve the app UI, a team of translators to localise the app to 7 languages, etc etc. Help is great but without anyone else involved full-time, I have to shoulder a lot of the burden for guiding those that are helping. One of the most challenging aspects of everything is managing software development time with every other task. Software development is such an involved process, actually the same can be said for other things such as social media marketing or interviewing potential candidates. All those are substantial time consuming tasks and over the years I have realized that unless there’s a hard deadline, they can consume a lot more than than originally intended. I had been thinking about ways in which I could solve that problem until I got to know about product plans. Product plan is a great way to compartmentalize your work or as we say in software engineering, ‘separation of concerns’.
The ‘Eureka’ moment
My background is in Computer Science and that too ‘hardcore’ computer science research which includes AI research in video games and robotics. I have researched on supervised learning methods with algorithms such as Neural Networks, Evolutionary Algorithms and Support Vector Machines. Therefore when I first discovered the Product plan, I was like “woah!! this is so cool”, which it “totally” is. I find the product plan synonymous to the “separation of concerns” design principle of which component based software engineering is an application. So according to me, a product plan and component based software engineering are related at a very high level, whereby you identify and compartmentalize your solution. Given that concept in mind, a product plan is not that different from a class diagram i.e. to conceptualize and implement a product plan, you need to consider various cross-functional teams. Hmm, maybe I am not explaining the analogy as clearly as I could? Anyway, let’s examine product plan , in more details.
The Wikipedia definition of a product plan is it’s “an on going process of identifying and articulating market requirements, that define the product’s feature set”. So it’s a continuous document about determining how well of a “market fit” a given product or it’s feature actually is. Also, what this means is that what I did in the first year (and a half maybe) of My Day To-Do updates could have been managed better. I haphazardly added features instead of preparing and following through on a plan. There can also be more than one type of product plan, the ones I know of are, an Internal product plan and one for external stakeholders.
External stake holders are those who only care about the performance of the business or better put, affected by the performance of the business. Now, what that means is that they do not need to know the nitty-gritty of how a particular feature is implemented, but rather how that feature will affect the business performance. So a product plan for external stake holders would typically include high level information for each quarter. For example,
- Feature X added in first quarter of 2019
- 20% increase in new user sign-ups & 40% increase in user retention in the 2nd quarter
- 60% increase in revenues by the 3rd quarter
This product plan would be something like horizontal bar chart with colored bars representing the objectives in each quarter. Like it or not, external stakeholders are important to the business and it’s important to keep them engaged and informed about your product strategy via a product plan.
Internal product plan
This one’s fun haha this may almost seem like micro-management compared to the product plan for external stake holders. In this one you focus on the nitty-gritty of it all and mention specific details on the execution of certain tasks. I recently made one of these for internal use at My Day To-Do, you can have a look at the full product plan by clicking here Internal Product plan. In that product plan you will see how I have planned or scheduled the My Day To-Do updates as well as some new apps that we aim to release based on some user stories.
This product plan is for internal organizational use and I think it looks a little more like a project plan i.e. since it has deliverables? actually, I just think it’s a odd hybrid of a project and a product plan, as it’s too brief to be a project plan and too detailed to be a product plan. Or maybe it’s just a product plan with one extra layer i.e. deliverables? or is the amount of information in it, bordering on micro-management? hmm what do you think? Maybe you can leave a comment down below and tell me what you think.
FYI, you may notice I have written some rather specific details in there i.e. In-app Hoscotch (LinkedIn) tutorial. If this seems like micro-management, well… more than anything this really is a reminder for me, since I am the only developer at My Day To-Do right now.
In that product plan, if there’s one thing that I need to re-think and adjust are the time allocations for the projects. As I said, being the only developer, I am often too conservative in my time allocation between coding and management tasks. I think this is partly due to my inability in calculating the context-switch time i.e. the delay caused in my mind to adjust to a new completely different (disparate) task. E.g. when I start coding a new feature for one of our apps directly after I have made a product plan or vice versa, in this instance my mind takes a some time to adjust to the new task. It’s this time, that I am still cannot successfully factor into my planning. I don’t see this responsibility of work changing anytime soon because while I have people who ‘occasionally’ help me with the marketing, icon design or market research, coding is still all up-to me. I tried hiring interns last year for some coding but yeah…. I wouldn’t recommend it for any other startup. In my experience the return on investment is extremely minor or completely unsubstantial.
In the first year, the process at My Day To-Do was this, I think of a new feature, make a plan for it and start coding it in from the next day. Last year, I had an MBA graduate working with me on My Day To-Do and he did his MBA things which made me take a step back from my “shoot first, questions later” approach to adding new features. An extension of that thought process would be the Kano model…
The Kano Model
Hmm how do I begin on this? ok, maybe it’s best I use a Wikipedia summary to start off with, “Kano Model is a theory of product development and customer satisfaction, developed in the 80’s”. It’s just a framework, tool, technique or very simply put, “a method by which which we determine how satisfied both current and prospective our product customers will be by our product features. So for anyone who thinks about using our product should be made aware of the value it provides them.
A different mindset
Thinking of the features in terms of the Kano model, really does enforce a different mindset to me. I mean, given my engineering background, so I would always think about doing (or building) cool things with tech, I didn’t care about how usable it was. I mean, “it’s obvious to me right? so the people who don’t get it, need to adapt to using it”. Yes, believe it or not, a lot of engineers think like that, I mean given how demanding our engineering degrees are, most of us are wired to think like that. It was that mindset which made my early startup journey somewhat difficult i.e. more so than now. Anyway, in comes the Kano model to free my engineering mindset and to get it to think about the product from the end-users perspective. I realise that I have made the above paragraph sound an awful lot like a UX mindset or so…hmm not sure how else can I put that. Anyway, before giving any more abstract examples or metaphors, let’s understand what the Kano model is
Kano model categories
The primary purpose of using this model is to gauge customer satisfaction and as such the goal is to classify a feature into one of the following categories.
This one’s pretty obvious, I mean think of the one thing that a product can’t do without or it will be pretty useless without e.g.
- The ability to add a todo in a to-do list app
- Taking a picture in a photo app
Can you imagine My Day To-Do (or any todo list app) in which you cannot add a todo? or if you cannot take a photo in Snap! I Was There or Snapchat. With the Kano model, we are looking at these features in terms of customer satisfaction, so the presence of these features won’t cause high customer satisfaction but the absence or poor execution of these will cause low satisfaction.
For the first year users experienced low satisfaction with this aspect of My Day To-Do. I don’t think it was poor execution but rather a design problem where users simply didn’t understand how to add a todo or mark a todo done. Actually, I take back what I said, it was poor execution that caused this. Anyway, these problems have now been ironed out with some UI tweaks and we have Firebase analytics usage data to support that belief.
Performance or one-dimensional
Ever heard of the phrase, the more the better? well this category is one of those things where just better than competition performance is what we are aiming towards. Ok, in the context of My Day To-Do, Performance was one of the first things that I thought about. I used a whole heap of other todo list apps and I found that the core function of such apps i.e. adding a todo was a little complicated in all of them. Ok not complicated but it was typically a 3-4 tap (or click) process, you could add a todo with a bunch of extra options but still I felt it was longer than it needed to be, which pushed some users away and back to using the pen & paper lists. This is one thing that I hoped to avoid with My Day To-Do so I kept the core feature i.e. adding a todo really simple. So when you open the app for the first time you will see that you are
- presented with an input text box which says “TAP HERE”
- once you tap, you will see a keyboard,
- you type your todo on the keyboard
- and press go on the keyboard
- the todo will be added to the list but the keyboard will stay
- so you can add many more todos like this
- should you need to add time, location or customise that todo, you can by opening edit todo dialog
I added all of the above to give it a pen & paper like feel so the users stay with it instead of going back to the old ways.
In terms of the feature’s execution, hmm well it could be better, we are back to the design or UX issue again. To this date, it’s not obvious to a lot of users that they have to push ‘GO’ on their keyboard to add a todo. How do I intend to solve this? Well, I just learned that you can create custom keyboards in iOS and I intend to explore that further and make changes to create a better overall experience for our users.
Remember we talked about the must-be feature category earlier? Well, this one’s almost the exact opposite. Must-be are features that the users expect and the app cannot do without but Attractive features are the one’s that the users do not expect. These features generally take the users by surprise and result in very high satisfaction with the product given it’s implemented properly. However keep in mind that, after initial surprise, with time, these features gravitate towards must-be features. The best example of this would be the iPhone, it was a surprise when first launched in the pre-smartphone era, Nokia dominated mobile world but now a smartphone OS is a must-be for any new mobile phone trying to gain any traction. Or you can say the same for capacitive and resistitive touch screens. Remember resistive touch screens?
In the context of My Day To-Do, it’s the Smart auto-reminders! In every app out there you need to set timed reminders for it to remind you about your todo, which in an extra thing that you have to do in addition to adding a todo. What if you forgot to set a reminder? Well, that’s why you have smart-auto reminders, with this feature the app sends you reminders every 3 or so hours with your list of unfinished todo. It will be a notification with all your pending things you have to do in the day, so it’s designed to act more like someone checking up on how you are going with what you had to do on the day. This is further an extension of the simplicity of My Day To-Do and our motto of “You do less” for our users.
How well is it working? I don’t know, for this one, I simply haven’t setup analytics to monitor this and based on our in-app user survey responses, I don’t think most of our users even know about this. Hence we need to work on creating awareness of this feature.
These are features that really don’t do anything for the user’s experience, they neither increase or decrease their satisfaction levels. They simply the invoke the ‘meh’ feeling from users or like “yeah sure whatever”. They don’t really do a whole lot to the users experience, therefore it’s best not to spend too much time and effort into them. Some real-life examples would be, will customers be more satisfied with the quality of milk if they knew the plastic that it was made from? Or would your driving experience be better based on side at which it had it’s fuel (gas) tank?
In the context of My Day To-Do, there are a few of those that I can think of
- The confirm delete dialog option that you can enable from Personalise (settings) tab
- The ability to color each alternate todo with grey color (I think this one’s more like a pre-cursor to set color on individual todo)
“Too much” of something is never good, as a wise Indian man (someone I know) once said, while eating rice if you feel there isn’t enough salt , you can add more but if there’s too much, you spit it. So excess of anything is bad, to the point that it’s detrimental to the user’s experience with the product. I think the best example for this is my most recent update of My Day To-Do, have a look at the screenshot to know what I mean.
The addition of the “Edit todo” button means, there are now 3 ways to bring up the edit todo dialog. You can swipe left on a todo, tap to hold or just press the edit todo button to bring up the todo editing dialog. I reckon this is a bit of an overkill for such a basic functionality. I had my reasons to do so, well it was just that a few users sent emails asking this as well as our Analytics data indicated that users maybe struggling with this. Hence I made it super obvious by adding that button but I don’t fully agree with this and I intend to consult our UX designer once he returns from holiday to come up with a better way to achieve this.
Phew!!! there you have it, a different post from some of my previous posts. I guess, this change or my evolution was inevitable, because I think for anyone that goes all in and invests in a startup has to evolve at some stage. Start looking at the business as a whole instead of just doing a bunch of engineering things that you think are “cool”. As I have said in the past no matter what you do, however efficient your code is, nobody cares, what matters is how can it help make your users life better. Especially if you are building a mass market product designed to for end-users. They need to be satisfied with it. USERS ARE IMPORTANT, very very IMPORTANT.
As usual, if you find any of my posts useful and want to support me, buy or even try one of our products and leave us a review on the app store.