From an Idea to an MVP

So I have this idea for food recommendation, but now I’m struggling with where to start. What will be a good first usecase for a POC or MVP.

At the moment, I’m planning on a single page dashboard where users can login to, to get a report on their food ordering habits – top dishes and restaurants and more such data.

But I have are two issues with scope:

  1. Not sure users will see the value that I see in such dashboard. Now, sure, that’s what the MVP is for, but:
  2. It’s not testing the real product assumption that users will want to get recommendations for food.

With that in mind, I thought of two other options:

  1. Dishes following – as a user, I can follow the food that I like and see updates, recipes and places I can find them.
  2. Group ordering – offer a simple ‘negotiator’ for food ordering. For example, a group of 4 people who want to order lunch, will connect to this page and put their preferences. The system will match their preferences and come with a suggested restaurant. Users can then save their preferences by registering. It reminds me of doodle.com.

I like the other option both because it requires less technical effort – I can see how I can pull out an MVP without writing a line of code. In addition, this can turn out to be a utility that users will be willing to register to. Lastly, solving for groups orders introduce the possibility for virality and network effect.

Developer for a day

Earlier today I demoed a simple search page that I developed as part of a 24 hour hackathon here at Outbrain. What makes this search page unique is that it uses the Sphere platform1 to find content that isn’t only relevant to the search query, but also caters to the user’s interests. So, for example, if I search for “python”, I’ll get articles about python, the programming language. If my mom, on the other hand, do the same search, she’ll get articles like this one.

But what I developed isn’t the subject of this article (I might write about it in a separate post). What I do want to share is my experience at putting a developer hat for a day. As a product manager, who works very closely with engineers, this turned out to be an invaluable lesson.

I had no intention of building anything in that hackathon. My plan was to help and support the hacking teams2. A few minutes after the hackathon began, though, I thought it will be cool to build this search page. Unfortunately, at that point there were no developers around to whom I could pitch my idea. All of them were already assigned to other teams. But I got this impulse to build something, so I decided to challenge my lack of development skills, and form a team of one.

Well, saying that I’m not a developer isn’t entirely true. Afterall, I graduated as a software engineer, I understand technology, I can speak intelligently about software architecture and design patterns, and I was intimately involved in designing and building the Sphere platform. I even do some coding in my spare time3. But, I’ve never coded with a mission or under a strict deadline. So I thought, this would be an opportunity to get serious about coding. Indeed, serious I became, spending the next 24 hours (minus 6 hours of sleep) hacking my way toward something I’ll be proud to present.

Here’s how my next 24 hours have looked like:

10:20am – 20 minutes into the hackathon I’m having this idea, and yada yada yada I decide to code.

10:40am – I can see what the architecture of the solution should look like, and what APIs I’ll have to use. It’s going to be easier than I thought…

11:30am – Hitting a dead-end. My initial approach won’t work, because I don’t have access, from the environment I’m using, to the API I rely on. Need to think of a new direction.

12:00pm – Found a new direction. I’m not sure it’s the right one, and I’ll have to learn a framework that I didn’t use before (well, I didn’t use any framework before…), but I’m running out of options, so I’m taking the chance. I find a tutorial, and hope to learn everything I need to know before the hackathon is over.

1:30pm – Urr… this is the longest tutorial ever, and it’s not even related to the use-case I’m trying to solve.

2:15pm – OK, good news and bad news. The good – I finally finished the tutorial. The bad – I still don’t have a clue how to work with this framework to build what I have in mind.

3:00pm – 5 hours have passed, and I still have nothing. What’s worse – people around me have high expectations of me. I have no idea why, but I know I’m going to disappoint them. I’m loosing my patience, and even the quietest chatter in the room distracts me. I’m agitated, and my fuse shortens by the minute. I hope no one will talk to me. I need silence. Maybe I should put headphones on, or go to a secluded room…

4:10pm – Half a day went by, and I’m farther away from my initial idea than I was 6 hours ago. Maybe some coffee and fresh air will help me regain energy and spirit.

4:20 – I don’t know if it’s the coffee or the time off the computer, but I’m thinking more clearly now. In fact, I have an idea. I need to run back to the office.

5:30pm – I have a working solution! It looks awful, but works…. all I have to do now is take care of the front-end. Easy breezy.

9:15pmI hate CSS. I’m about to loose my mind. I must eat.

10:00pm – I need to have some sleep. I’m sure things will look easier tomorrow.

8:10am – CSS is still CSS.

9:55am – 5 minutes to my demo. With some help, hand-holding and a lot of duct-tape my work is somewhat presentable. I hope people see the potential, and won’t get caught-up with the UI.

10:10am – I’ve just presented my thing. I feel awesome. I built something and got people’s applause.

Now, what did I learn from this schizophrenic experience:

I don’t want to be a developer.

Yeah, as simple as that. I’ll keep doing it as a hobby, but I’ll never do it professionally. I mean, I love the problem solving, and creating something with my own hands is amazing. But, getting sucked into the smallest of details, spending hours trying to figure out what I did wrong, only to find a missing ;, and wasting tons of time on configuration before I can do anything, make me go nuts…

OK, so as this door is now closed, what did I learn about coding that will help me understand engineers better?

Coding requires focus

Soooo much of it. Even the slightest distraction can throw your thought process miles away. It then takes a lot of time to regain your thoughts, and get back to where you were before. I now understand even better Joel’s “Human Task Switches Considered Harmful” post.

Tools are important

Don’t ask why, but I’ve started to learn Emacs recently, and so far I love it. But, Emacs isn’t the most dummy proof app out there. Here’s a funny chart, that actually stops being that funny when you start learning Emacs:

3251176498_c3485a55fb.jpg

So, since I’m somewhere at the bottom of the learning curve still, I thought this hackathon would be an opportunity to learn the tool better and faster. But as soon as time started to press on me, and at the first instance when I didn’t know how to do something in Emacs that was trivial in other tools, I closed it and opened the other tools I feel comfortable with (Sublime and CodeRunner).

Knowing what’s the expected outcome is key

Having a clear idea of what my end product should do, and to some extent – how it should look like, was crucial. I had so much to learn in a very short time, but knowing what my end goal was kept me focused. It also helped me stay on course and learn only what was relevant to getting my project done (otherwise I have the tendency to drift away quickly).

And lastly, I experienced first hand how deadlines and quality [don’t] play [well] together:

Code becomes crappier as deadline approaches

You might think that my experience isn’t a good enough example, and I might agree. I’m just saying that now I can better relate to this #NoDeadlines trend.

If you’re involved, at any capacity, in product development, you already know this lesson, because crappy code keeps bouncing back at you and eats the time and resources you need in order to build new stuff. Don’t be fooled by fancy terms, such as “tech-debt” and “refactoring” – these are politically correct ways to refer to crappy code. And the stricter the deadlines, the more of it you’ll get4.

So with that, I’ll put my developer hat down. It’s too big for me…

Footnotes:

1

Check out the platform here, and leave a comment if you’re interested to learn more.

2

There were 19 internal and external teams hacking.

3

In case you’re interested, here’s my GitHub account.

4

No, it doesn’t mean I won’t ask for time-lines and set deadlines in the future…

On Collection and Vision

Marimekko is one of my favorite stores 1. Whenever I go in there, I get filled with excitement and urge to swallow the entire collection. I’m fascinated by the vibrant colors and the unique, yet simple, patterns. I’m compelled by the layout of the store and by the arrangement of the items. When I’m there, all I’m thinking about is how to make my home a replica of that store.

IMG_5090.jpg

Figure 1: Marimekko on 5th Ave., NYC

 

Unfortunately, I can’t afford taking over Marimekko yet, and even if I could, I don’t know what would I do with hundreds of yards of beautiful fabric 2. And so I have to limit my focus to only one, maybe couple, of items at a time. But when doing so, much of the early excitement vanishes.

When looking at each of the items separately, they don’t look as compelling. A colorful serving plate loses its charm when I figure it won’t fit our current portfolio of dull white dinnerware. A Puisto-osasto print bag looks great, only until I see it’s a tote style bag, which I would never dare to carry. A sofa pillow with colorful flowers’ print, which is Marimekko’s signature, is stunning, yet won’t make it to our subtle, minimalist living room.

So beautiful as a whole, less so when zooming in. And so I usually leave the store empty handed (sometimes with yet another espresso cup).

I use this metaphor occasionally when talking about the difference between vision and the parts that make this vision a whole. I use it to explain to my team why is it that an inspiring vision turns into a list of less exciting projects: improving our api by exposing more resources’ types or adding attributes to existing ones, keeping high standards with our internal tools, even if they don’t add direct value to our users, or designing and developing pixel perfect internal reporting dashboards. These are efforts that don’t always make sense if you look at them in disjunction from the bigger picture, and see how they become part of a comprehensive product in aggregate.

At other times I use it to give some perspective to a feature owner who feels disappointed when the feature she just released didn’t take the Internet by storm. I explain that when building a platform, it’s unlikely that a single feature will “steal the show”.

A vision, like the Marimekko store, excites and inspires only when viewed in its entirety. When you dive into the details, the products and features that comprise it, you might loose your initial enthusiasm.

If you’re in a leadership position, remember that while you live and breathe vision, your team is soaking in the details, and in the day to day tedious work that is anything but exciting. Your challenge will be to inspire them, and keep them inhaling the dream. Otherwise, your team’s morale and its motivation to follow your lead towards fulfilling your vision will quickly evaporate. Thus, the collection you envision will turn into an incoherent pile of items that look bad anyway from near and far.

Footnotes:

1

I’m referring to Marimekko NYC Flagship Store. Here’s where it located.

2

I do try to find uses for their fabric, often as a gift wrap for special people in my life.