A few years ago I had the idea of improving the teacher evaluation process. At the time, the best practice for schools was the old hand written evaluations that would then get stored in a file box on some shelf.
I felt this was ripe for disruption. I had a couple potential partners involved who ultimately wanted to make a much bigger product with a lot more features.
I ultimately was turned off by the undertaking this new product was going to be and decided to let it slide into the background. Shortly thereafter, I pursued a failed business.
Realizing the Lean Startup Methodology
The idea of the Lean Startup is to launch a “Minimum Viable Product” (MVP). In a nutshell, an MVP is a product with the bare minimum features that someone will pay for.
This is often confused with just throwing some garbage together and thinking people will use it. The interface and usability is still a major factor here and so many times developers just completely overlook this aspect. The product still needs to be desirable!
Here are a couple of visuals that illustrate the MVP philosophy:
In this image from Jussi Pasanen, you’ll notice that what you are working on (light blue area) should touch on all four of these major aspects (functional, reliable, usable, emotional design) and not just the functionality part.
This image is from FastMonkeys (this link takes you to a great guide they put together on MVP’s). It illustrates the point about not necessarily knowing what your end product is going to be, but at each step of the way (in the second scenario), the product is functional. Let your customers help you shape the product.
I didn’t know it at the time (because I hadn’t read about it yet), but I was already a believer in the lean startup methodology.
I wanted to focus on a core form functionality and keep the product simple. Think of a Wufoo or SurveyMonkey, built specifically with idea of building teacher evaluation forms.
The partners and I weren’t quite on the same page with this, which made it hard to move forward.
Revisiting the Idea
A few months ago I decided to look back into it. Before doing anything, I decided to reach out to some local schools in the area to get some feedback.
This is one of the biggest takeaways you should have from this post. I did not set out to start building the app, but instead went and tried to talk with potential customers first. This should be done before writing a line of code or even putting up a landing page. Once you have the basic idea and you want to see if it has potential, the next step is to talk with potential customers.
So I gathered up some contacts at ten local schools. Now, I had a contact in this space who had the right contacts, but I could have easily used the state’s educational site and many other avenues to find the right contacts.
Once I had the contacts, I sent the following email:
Why I chose those three questions:
1. You need to make products people actually want/need.
2. You need to make a decision on the bare minimum feature set your product needs in order to start charging.
3. You need to make sure you know that your target customers would indeed actually PAY for something like this, not just tell you “that sounds cool.”
An alternative approach would be to talk with people in a specific industry and find out what problems they have. Go in with no preconceived idea and let the commonalities of feedback decide where you go with it.
Product Idea Validation and Feedback
I wanted to monitor the responses to ultimately determine if this was going to be worth the effort.
I ended up with feedback that was across the board. Someone said I shouldn’t bother, another had full fledged feature requests and wanted to be a testing school.
Here’s a few snapshots of some of the feedback:
The yellow highlighting is from searching my inbox for the email threads, not me trying to emphasize anything.
Why The Feedback Matters
Since the feedback was all over the place, it didn’t help make my decision any easier.
When I looked up this space a couple years ago, there was really NO ONE in the space. First page of Google for the term “teacher evaluation software” was actually just a list of results that linked you to various evaluation forms you could print off and use in the classroom.
I decided I had better check to see what was happening the space now. I went to Google, and sure enough eight out of the first ten results were all software driven applications for this exact purpose.
Since the feedback was fairly scattered, and competition had already come in full force, I decided to let this idea go. It’s important to not get too attached to your idea, so that you can be flexible and test other ideas.
Had the feedback and research warranted further development, I would have set out on a plan to map out the key features and what I needed the software to do.
I probably would not have invested in the design at this stage, just because the Bootstrap design framework is pretty enough for this stage. Once I had users in the system trying things out, I would have invested in a custom design.
The interface is a critical element and should not be taken lightly. The difficulty, ironically, is in trying to keep the interface simple. By taking this approach, you save a ton of money and even more time in ensuring the product you are building has a market and is helping solve a need.
In my case, I probably missed an opportunity a couple of years ago with this idea, but I was able to save my time and money by not jumping in head first when I went to re-evaluate the potential.