Michael Domanski shares lessons learned as an entrepreneur on doing customer discovery to find a minimum viable problem.
My Journey – Customer Discovery to Minimum Viable Problem
first printed on Lean Startup Circle Blog by Michael Domanski
Hi, my name is Michael Domanski and I was born into a family of entrepreneurs in Poland. For a long time my father ran his company production from our garage. My mother used to run a shoe shop and then her own shoe sewing services company.
Having such a background, I tried finding my own way and ended up at Warsaw Tech University studying computer science and electronic engineering. While the subjects I studied were more or less interesting, the dorm life had a serious impact on my career, since I ended up living with people connected to the growing tissue of startup companies in Warsaw.
After the first year I started looking for a job and got myself hired in a startup. And that was an eye opener. Fast forward to April 2012, I still haven’t worked in a company that isn’t a startup. And I slowly realized that I had ideas for a tool that could be used by companies facing product management problems.
The beginning
In April 2012 I worked in a startup where the phrase “lean startup” was used so heavily people rolled their eyes when they heard it again. At the time I had no idea what they were actually talking about. And it turned out, nobody had. CEO pitched it heavily, but no one really took time to read any of the books.
I was driven to find out what “lean startup” was really about. And right away the whole idea seemed familiar. I was always interested in designing user experience, had some knowledge about the engineers approach of solving problems and used to work during summers in shoe shops – so I had some hands on experience about finding out what people need.
The idea
At the university and at work every day I looked at the problem of real life work scheduling, since engineers working at startups usually lack management skills. In particular, people were miscalculating deadlines, not considering task dependencies–is my work critical for someone else–or who was best suited for a particular job or task.
What I realized was that problems such as:
- Task dependencies
- Task duration (how much this should take?)
- Task assignment (who is best fitting to do this?)
can be solved by analyzing historical data, trends and simple human errors stored in the project management software. Like a static analyzer but for a project plan.
Since I was heavily into iOS app development at the time, my original idea was a mobile app. Having skepticism in my DNA I asked my friend, who at the time had successfully launched a really lean startup in the area. We talked for a while: people don’t plan a month using an iPhone. A pivot was needed to find a minimum viable problem.
The pivots
I was back to the formula, trying to find a way for this to work. I knew already that this has to run on a desktop, so I settled on a web app. Then I started to think about a basic set of features and came with this:
- A web app, with monthly subscription
- Task owner suggestion, based on skill, previous records and current workload assessment
- Visualizing who does the task and to what time frame it all adds up
Next I made a launch page with some statements what I intend to do, submitted that to betali.st and waited for email responses. I received a few that led to productive customer problem interviews and others that suggested ways I could improve my landing page.
The first few days on betali.st earned me a few hundred emails, as it turns out people love productivity software. I later turned this list of emails into mailing list and asked people if they wanted to help me with a short interview. Less than 60 actually opened the email, around 10 agreed.
The good part is that I had some good hits: people in crisis management, startups, and people in small companies working all over the world. Here is what I learned:
- People already have well tested solutions
- They mix a lot of real life objects like paper and whiteboards where software is lacking
- They are less than interested in using my untested platform
- They have a lot of data in their current tool, be it Basecamp or AtTask and they don’t want to move
I also sent emails to various people listed on http://leanstartup.pbworks.com/LSC-People-Willing-to-Help-with-Pitches asking them for feedback on my idea. A few responded, including Hiten Shah and Sean Murphy, who became an advisor on this trip. Bottom line here is: keep trying, patience breaks through walls.
Current map of problem
The problem space various people face when working with task/project management tools is so vast that trying to be better just by fixing all of them was a bad idea. More research on work management solutions led me to realize that there were more than 80 with APIs, but they differed only in details. To deliver value I didn’t need to develop the whole task management system. I could integrate with the API, and most of the big players in the field of work management have public API.
So the characteristics of my potential customer looked so:
- A small company, staff somewhere between 10 and 50 (we like smaller companies)
- Company doing creative or knowledge work – like a startup, software house or creative agency
- Uses tools like Basecamp, Zoho, or AtTask as work management tool (or other similar systems with an API we could leverage)
- Many to many work scheme (many people working on many projects)
- Projects require more than one person, typically with different skills
- One person works on several projects at the same time
- Projects / design projects requiring specialized expertise or knowledge
Now I needed to find contacts that actually fit this profile. Again, I turned to my mailing list but that gave 0 result. Then I’ve spotted one interesting pattern. I was reading through 37signals blog and they’ve mentioned people blogging on their own pages how they use tools made by 37signals to improve their work.
So I’ve turned to Google and started combing the network for people blogging about how they use Basecamp. After a few hours I’ve sent less than 30 carefully aimed emails and went back to trying to write a decent blog post.
Surprisingly the cold email tactic worked and I did got some very high quality interviews. The interesting part is that those who responded were the biggest players in that batch, with the most sophisticated setups and turning serious profit.
Where are we now?
We are working on finding a Minimum Viable Problem that’s serious enough to get paid for solving, but small enough to:
- Deliver MVP (Minimal Viable Product)
- Measure the effects
- Iterate with it or toss it out in a short period of time.
The problem space is quite large and to remain sane we did have to pick one vector of approach.
We have a website for the project up at teamwork.mdomans.com [archive] with a blog [see postscript below] and a twitter feed @getteamwork [deprecated].
Sean Murphy‘s perspective
I find the small team collaboration environment to be an exciting space. It’s one that I have worked personally on and with a number of companies. One of the things that was most interesting about my early conversations with Michal was that we were both wrestling with how to describe–and support–teams that were “in flow. They were able to stay on the same page about a problem but work on a number of distinct issues in parallel to create a harmony that was greater than the sum of the individual team members actions.
Our first interaction was working through my “The First Seven Questions Any Product Plan Should Answer.” We walked through the answers three times, refining them and shifting the focus to what we could build on top of existing popular project management tools instead of replacing them. In the first month we looked for what was missing that we could add to complement.
We also reviewed a number of different experiences each of us had working on teams, good and bad, and felt that there was considerable value in supporting flow at a team level. We challenged ourselves to focus on what could we offer to help a small team that wanted to move fast on creative or complex problems. We briefly considered “crisis management” as a focus and then narrowed it to creative teams. Crisis teams may make for a great Act 2.
Next steps
We continue to look for small teams using Basecamp, Zoho, or AtTask as work management tool. Often they are using many other tools in addition (e.g. Google Docs, Dropbox, GitHub, Skype, GotoMeeting, etc..). If you are interested in working with us or open to an interview on how you manage their workflow, we are very interested in your experiences, perspective, and any insights that you would be willing to share. We promise to be respectful of your time and offer early access to our case study in return. Please use the contact form at [deprecated]
Related Blog Posts
- 8 Tips For Interviewing Experts
- Preliminary Results From Research On Managing Creative Projects
- Q: How Do I Make Sure I Understand The Customer’s Problem and Present a Vision of a Solution?
- Q: Should I Pre-Sell My Product?
- How Founders Should Should Manage Startup Runway
Image Credit “Graph Notepad and pen” (c) Milkos Licensed from 123RF 71350317
Postscript: What IT leaders can learn from air force pilots
Written on June 20, 2012 by Michael Domanski
Air force pilots are a highly trained group of selected individuals who spend most of their time improving their skills. They require almost no communication with each other except for key moments. And their work allows no margin for error.
So how can one learn to manage in a crisis situations or complete a task when problems start to show up. One of the key parts of pilots constant drill is briefing and debriefing. Each maneuver is discussed and almost all possible problems are discussed. More experienced pilots teach their colleagues how to manage different situations.
The algorithm is simple. One has to assess the situation and gather data. Then he has to make lighting speed decision. There is little time for comparing solutions when you’re flying 16 tons of steel 3 meters above ground with speed over 300mph.
Time is priceless
I recently interviewed one former pilot about problems he had and how he managed. He was maneuvering in tight formation when leading plane suddenly took turn. He went through his exhaust streams and his engines went silent a few meters over ground.
He checked the engines to see if they’re dead or still working but just choked. Assessed speed and altitude, to catapult if things go really bad. He couldn’t go up because he hadn’t had enough speed. So he let the plane gently go down to gain speed, cut few bushes with his fuselage and gently started to pull up. All this in less then 2 seconds.
There was a key moment there. He recognized the situation and then analyzed solution number 1, then solution number 2 and went for it.
He never had time to compare possible solutions and never was in exact same situation before. So how he could recognize the situation so fast? Partly, because he was drilled on simulators. And he had a lot of flying practice. And he mercilessly briefed on what other pilots did in such situation to survive. Thus he had a prior knowledge of possible, tested approaches and recommendations.
There is a core of knowledge passed on through word of mouth and notes and lectures based on real life experience. Fire brigade commanders use this approach. And it’s also used by many leaders and managers in other fields, be it ICU, military, stock trading or IT management.
Can you take the first step?
Getting through the crisis is proper situation assessment. And frankly, you can’t do much here if the situation is entirely new.
This was proven time and time again. There are documented cases of fire brigades taking time to consider their choices since they had no prior experience with the task at hand.
So how can you get through in a new situation? Learn on others knowledge and mistakes. There hardly exist an entirely new problem. We repeat lessons known by others. Pilots are briefed and debriefed. The same goes for SpecOps. Project managers call this technique „lessons learned”. There’s a pattern and you should use it.
Is “lessons learned” for me?
Was captain Picard ever doing pointless things? Captains log is essentially a lessons learned done over a very long project. Writing down ones knowledge is a very powerful technique. It has two major points.
- It’s easier to remember symptoms. Recognize problems ahead and react preemptively. Our brains work like this all the time. I see my car is running low on gas, I don’t wait till it stops, I go the the gas station.
- Lessons learned is a phenomenal tool for taking ideas from your head and giving them physical existence. In fact, for many companies “lessons learned” is a valid basis for making decisions. Instead of repeating mistakes, we act on what we know.
And maybe it’s only me, but when I do simple notes along the way, it’s easier to talk about the problem when I need to bring someone up to speed. Proper code comments are a very concise “lessons learned” version.And I do appreciate them as it frees me from hours of Googling for explanation or bothering author with questions. Instead, there it is, a short snippet of knowledge, why something is as it is.
So, what are “lessons learned” really?
Structured recording of acquired knowledge relative to some problem area. E.g. I’ve got some experience scaling services. So once a week I take 15 minutes to write some notes why I did what I did. Sometimes I add a link to ticket (so we have problem background) or attach some files (a server log).
After that I outline symptoms (e.g. all app is running fast, but searches are slow) and describe how to quickly validate if it’s really the same problem. Then I outline the solution I used and why, how it worked and where it’s limited.
Last important bit here is to make easy to share, search through and access for others. So it’s ok to use Excel, but it’s better to have intranet wiki. Or a shared Google doc. This is very important. Searching through notes should be as easy as googling which movie is the best for Friday evening. Just type your query and search. If you get zero results back, you know you’re on stranger tides.
Final thoughts Do not let the knowledge to be lost. If you can remember reasons for each professional decision you’ve made, you’re probably Vulcan. Make notes, read others notes, try to collaborate and share. If you got five collaborators to a single system,adding their thoughts and remarks each day you will gain a week’s worth of knowledge. Do not repeat yourself.