Last week was insane. I don’t think I’ve worked so many hours in a long time. My conservative estimate is 85 hours alone with my business partner in for another 70 or more. We are working on a contract job — got to pay the bills some how as powerOne has become a labor of love — and it all came to a head last week with a deadline for today. We made our deadline. Why so many hours at the end? Because there were too few hours at the beginning.

We have never done much contract work before this past year, at least not stuff that isn’t calculator related or where I am closely guiding the development requirements. This year we have done two such projects. The one early in the year was extremely well specified. We knew exactly what we were responsible for, how they wanted it done, and had header files of everything we needed to interface with. While the coding was different in some ways from anything we had done before, the project was well defined and very straight-forward.

This project, though, was open-ended. We had a basic requirements list but not much was well defined. Even the requirements list was fluid. So here are a few things I learned from this project:

1. Force a refined requirements list. I shouldn’t have bid on a project that was quite so fluid but I did. It’s a start-up, they are moving fast, and the project was right up our alley. Plus, they had a two month window so I wanted to get started. So we did.

Honestly this wouldn’t have been such an issue if we would have had more domain knowledge. But this is one of the few times in my career I developed a product where I didn’t have a sense for the customer.

2. Mobile is not the web. This is one I knew but reinforced once again here. In essence the partner company said here’s the website; go play with it. I did a little but given that it wasn’t my domain expertise and the site was complicated, I didn’t play enough. When developing, every layer we peeled off the site showed even more complexity. I didn’t understand the full extent of code required and not sure I could have from “playing with the site.”

3. Specify, specify, specify. Which leads me to #3: I should have focused everyone on creating a specification right up front. What did we need? How many layers were there to the site? How would we simplify the entire site to fit the mobile paradigm? We thought we could do this as we went but that was a problem. We spent too many hours re-writing code and their designer spent way too many hours writing APIs for features we didn’t use.

I had a professor who once said that writing an app is 70% planning and 30% coding. What he didn’t say is that most of that 70% needs to happen up front. As I mentioned, normally not a problem as usually I write apps I understand inside and out. But when writing for someone else, especially in a domain I don’t know? More planning up front.

4. Someone must be in charge. There really wasn’t any one in charge of decision making and planning on a day-to-day basis, or more accurately it was shared. The CEO of the company we were developing for is really a sales guy, so feedback came late in the process or not at all. Mostly we were left to make our own decisions and sell them to the company, but it took us a while to get the hang of that. Luckily, the company CEO is a very reasonable person.

5. UI first or data first. Every app I have ever written started with the UI. We designed what we wanted it to look like, the features we wanted, and then built the models to match. I spent the first few weeks of this project completely frustrated because this project was the exact opposite and I didn’t realize that. In this case the data (because of the web app) was well-defined and we should have started with the models and then built the UI from that. We started moving forward once we figured this out.

6. Simplify. I preach this over and over again for our own consumption. The same is true for contract jobs. There is never a UI or data model that can’t be simplified further. Again, so thankful the company’s CEO was so reasonable. I do hope they take these lessons and bring them back to the web.

Outside of the intense process at the end, it turned out to be a decent development project. I hope we can get back to working on powerOne and Equals, though, and that we can figure out how to turn those into sustaining businesses. I really don’t like writing code for other people’s ideas.

I was at a breakfast meeting yesterday and we got to talking about minimum viable product (MVP). I’ve written about this before, basically saying how speed of development and MVP are not synonymous. But the question arose: how do we know when we have a minimum viable product?

Before I answer that question, though, I want to make sure we all understand this incredibly important concept. A minimum viable product is the least development you can do to give your potential customers the idea of what you are trying to accomplish, what benefits this service/product might bring to them, and give you a feel for the revenues and costs associated with delivering the service/product. The point of MVP is to get those of us who are inclined to sit around the office and develop apps out of the office talking to customers.

Dropbox famously built their MVP as a video. I’ve seen paper reproductions and I’ve seen code. Sometimes wireframes work or a nicely mocked up PowerPoint presentation. Every one of these can get the idea across and get a conversation started. In fact I could easily argue that the less code you write the better off you are. [1]

It’s important to understand that most people can’t imagine what you are imagining. They need to see it or touch it to truly get it. And that’s why words on a page or a concept in speech is simply not enough. Physical is better. The decision about how to get that across to a customer, though, is up to you.

When we started working on an MVP for Equals we decided we needed to write code. The concept — writing a note that can tell the difference between text and numbers, performing any mathematics automatically — was hard to imagine. We felt it was important to show that ability so we started with an MVP that did just that and over the course of months refined its capabilities.

We also realized that there were a number of other things we wanted to test as well with customers. Would sharing be of interest? Would being able to send things to third-parties like Evernote, Twitter and Facebook be important? What about collaboration? History? Integrated data?

Some of these things were natural offshoots so we didn’t need to develop them. Once people understood sharing the idea of collaboration was a natural extension, very easy to discuss. Some we could put screenshots in place that simulated the look-and-feel but didn’t actually function. I didn’t have to build Evernote, Twitter and Facebook integration. Showing a table with those options was enough. When we developed the first Equals MVP we included no text formatting. We talked to potential customers about the idea but found that it didn’t stimulate a conversation. So we added functioning code. [2]

Once again, back to the original question: how do we know when we have a minimum viable product? We know when we have a hint of all the features we want to get a reaction to from the customer. Those features need not be complete and in many cases they don’t even need to be functioning. But they do need to spark a conversation.

After all, the whole point of the MVP is to get a sense from customers as to whether we are on the right track or not.

—

[1] This goes especially for non-developers. Stop asking people if they’ll write an app for you based on an idea. Mock the thing up in PowerPoint or Keynote using a tool like Keynotopia and go get customer feedback. That’s a heck of a lot cheaper than writing code.

[2] We also needed to prove we could do it in a cross-platform way.