I get frustrated seeing ideas come out of various accelerator programs and at least one or two of them are something I’ve “thought of.” It’s not that I am frustrated that another team is getting success/validation for their idea, I’m frustrated because I let my idea languish and spoil in my mind when I know I could have done something about it.

It takes commitment to make something from nothing, but I’ve been learning a lot lately from people in the NY Startup community on how to strategically build a product with as little waste as possible.  I’ve benefited a lot from Skillshare and the people who’ve taught classes that I attended: Michael Karnjanaprakorn, Vin Vacanti, Spencer Fry, and Chris Dixon.

After attending a few classes, I wanted to take some new thoughts and put them to practice. As David Cancel would say, Just Fuck’n Do It (#JFDI).

The next few posts chronicle how I went from a simple idea to a fully functioning (be it rough around the edges) product in 7 days.

Day 1

The Idea

Yumalicious (http://yumalicio.us)

It’s show and tell for people who love to cook. I love FoodSpotting.com, but it’s about the extraordinary food that you can buy and consume.  I also love Dribbble.com, it’s show and tell for designers. I wanted to merge the two and make them about something I’m passionate about, cooking!

User Flows

Before I started trying to figure out what sort of functionally I wanted to implement, I needed to think about how a user interacts with the site. I gave myself an hour to sketch it out and think about how someone would interact with the site I wanted to create. I knew the tasks I wanted them to do and they were as follows:

• Upload a dish with a photo, title and description.
• View the dish and be able to comment/discuss it.
• View a chef’s profile and the dishes they’ve submitted.
• View the newest dishes submitted to the site.
• Follow a chef
• Favorite a dish.
• Register for an account, login, edit profile, reset/forgot password.

Data Modeling

I love thinking about how to represent ideas as bits of information.  Looked at my user flows and began defining pieces of data that represented the information. I started from a high level view and thought about the distinct “objects” of information:

• User
• Dish
• Comment

From there I looked at how these objects were related and then started filling them out with details. It’s a simple exercise that only took a few minutes to do.

Wireframing

I will be honest; I love the idea of wireframing tools, but I don’t find them practical.

I sketch out the general layout of my pages in a notepad, but I do all my detailed wireframing within my project. After playing with Balsamiq, Visio, Omni Graffle, etc in the past I found that the best tool for me to plan out the structure of a page is using basic HTML and a smidge of CSS. It’s not that that these tools are bad, I just find I save time since I don’t have to do the work twice (once in Balsamiq and once during implementation.)

This also allows me to touch and feel my application as it evolves and limit having to maintain two versions of the same thing.

Scrum Time!

I love agile, but I’m also very informal and unconventional in how I do things. However a little structure goes a LONG way. I set up a scrum styled task board that only has 4 columns:

• Product Backlog
• On Deck
• In Progress
• Completed

Each task that goes into one of these columns is a simple User Story. A User Story is a short description that defines a piece of functionality. I took the list of flows and broke them down into atomic descriptions of functionality.  Here are some examples:

• Allow a new user to create a user profile and attach an image.
• Allow a user to log in to the site.
• Allow a user to upload a photo with a title and description.
• Allow a user to view a submitted photo.
• Allow submitting user to edit a photos title and description.
• Log a view count for a unique visitor to each photo viewed.

After I created a list of user stories, I then prioritized them. They were prioritized by how important the functionality was and their dependencies.  For example I would prioritize “allow a user to upload a photo”, but also prioritize “create a user profile” and “log in to the site” as user profiles were required to post a photo.

This prioritized list would then go into the Product Backlog. The product backlog is the prioritized list of ALL user stories you come up with for your product. Even stuff you want to implement 3 months from now. One thing to note is that while I prioritized the Product Backlog I also made note to prioritize in order of what I felt would make a “complete” first product. I drew a mental line in the sand in which I determine which things are “nice to have” vs. “must have”. The “must have” stories always were moved up the list.

Once everything was prioritized I then started moving tasks into the On Deck column. This column represented a small set of tasks I would like to get accomplished before the day ended. User stories would only make their way into the “On Deck” column when I was highly confident if it was something I could accomplish within a given period of time.  Typically this limited me to only have 6-8 items in the On Deck column at any given time.

I would move something out of the On Deck to the “In Progress” column once I was ready to commence work on those stories. Most of the time there was only one task in this column at any given time, but sometimes there were two or three if they were connected.

Once a story from the “In Progress” column has been completed, I move it over into the “Completed” column. Typically if there were more people involved I would have another column that included a “Review” of the story, however since I am the only one working on this project I would bundle reviews into the “In Progress” column.

After something was moved from “In Progress” to “Completed”, I would then promote a story from the “Product Backlog” into the “On Deck” column.

Any scrum/agile purists may cringe at this, but I deviated from a lot of parts because I knew they would only get in the way. My goal was not to make a process, but to make a product. I stripped down the process and threw out things that didn’t need to be there because I knew my limitations of working on this independently.

Technology

I love exploring new technologies, but I’m also a proponent of “go with what you know.” As a developer I feel confident that I can build what is required, so my goal was to flex more about the things I wanted to learn. Specifically I want to learn more about Product Management, Usability, and Online Marketing.

The goal for me was to “Just Fuck’n Do It”. I didn’t want to create excuses for myself by giving myself time to explore interesting technologies. This project was more about the idea than it was about the nuts and bolts.

For the technology I went with a fairly simple stack:

• Java
• Apache
• MySQL
• Tomcat

I like Java and I’ve been using Java for a majority of my career building technology for companies with large-scale websites (e.g. MLB.com, Nick.com, FoxSports.com, etc.). I know it and I feel confident in how to scale it.

Cassandra & MongoDB are great products. I really find them interesting, but I found that there were some things I didn’t want to deal with now. Either way I’ve architected the data access of the site in such a way that I can quickly migrate to another data store when the time comes.

For an MVC framework I went with Spring Frameworks as it’s fairly simple and VERY robust.

Implementation

After the “Product Backlog” and “On Deck” had stories in it, I began to get to work. The first items On Deck were:

• Create a unique user account
• Allow the user to log in
• Upload a photo
• View photo

These were items that I had determine were “vital” to getting the project going. The main purpose of the idea is to share what you’ve cooked. In order to do that you need to be able to create an account and upload a photo. After you create an account you may want to come back and upload more photos, this required me to let the user log in. When a photo is uploaded there needs to be a way to view it. That was what I wanted to get done after a days worth of work.

Instead I was able to move through those relatively quickly because I kept everything simple. I then moved a few more items from the Product Backlog to the On Deck column:

• Comment on a photo
• View user profile
• View newest photos
• View users photos

One downside of using the stack I was using was that I was repetitively creating similar objects over and over:

• Bean/Pojo
• Data Access Object
• Service Layer
• Controllers

Setting this up isn’t very complicated, but it was a task I was repetitively doing over and over. I talked about that with a friend and he told me to check out the Spring Data and I started using it for new Data Access Objects I wanted to create.

Conclusion

Day 1 was by far the most important day as it’s where everything is done to pave the way for the next few days. The planning and laying out the idea was time well spent. I may even argue that the planning was more important than the coding because it made the direction all that more clearer.

Next Steps

In the next posts I’ll talk about some of the more interesting UX and Technical challenges I ran into.