I’ve been diving into different product management – importance of roadmap and product prioritization and then a RICE framework for prioritization. Today, wanted to jump back in but look at story mapping. I haven’t done a story map before, but I’ll share what I’ve found reading up on several sites including Aha!, MANIFESTO, Agile Velocity, ThoughtWorks, and others.

The benefit of story mapping is its effectiveness as a visual tool to organize the development tasks and activities with goals – the stories a product/ service user traverses. It prioritizes for value and aligns the team on value and goals.
How to think of story mapping – my preferred route:
  • There are two axes – from left to right, the goals a user accomplishes to achieve a greater goal (e.g. make a purchase, stream a video, other). From top to bottom, the prioritization of stories (activities/ tasks) organized into a release schedule.
  • At the top level, you have the intermittent goals a user achieves. All tasks and activities that help accomplish this goal fall under. For streaming a movie on Netflix, for example, the top-level goals, these can be: “Find movie”, “Assess movie (details)”, “Select movie”. 

  • Under each goal would be the activities to accomplish the goal – the stories a user undergoes. For example, under “Assess Movie”: “View movie trailer”, “View movie description”, “View critics rating”, “View user rating”.
  • Take an iterative approach to the story map where developers, product managers, and customers review the stories for gaps… adding missing stories and removing redundant stories.
  • Evaluate which stories are critical for the first release – this may create the “MVP”. You could prioritize stories by “MUST”, “SHOULD”, and “COULD”. Assessing the stories, you could draw a line that demarcates the stories into the releases (or MUST, SHOULD, COULD).

  • Utilizing Post-It notes is a fantastic way to create these maps offering flexibility and color-coded stories, goals, etc.
  • Keep story maps focused on achieving specific outcomes and performing specific tasks for a target persona. Then, create other story maps as needed.

These are the highlights of utilizing story mapping in the realm of product management. It’s an effective route to hash out the activities to accomplish a user goal.


What are other methods for managing product development?
Given deadlines, budgets, and other limitations, entrepreneurs should opt to trim the scope of a product/ feature list over sacrificing quality. Of course, if entrepreneurs are truly building an MVP, there won’t be too much room to trim.
In cases I’ve alluded to in my previous posts, many startups and wantrepreneurs make the mistake of jam-packing version 1.0 with several features without giving much attention to quality.
Having started a development shop recently with a couple previous partners, we must manage expectations. Many clients ask for feature-filled products from the get-go. We’ll provide them our thoughts on a more lean approach, but also give them what they asked for. Unsurprisingly, many companies and wantrepreneurs are sticker-shocked… some naivety to the technology and development world, many believe coding/ programming is simple and can be done cheaply.
With a budget half of our estimate, many still ask to fit all the features in believing they can sacrifice some level of quality in favor of more features. However, we push back – trimming scope rather than quality knowing that delivering all of the features would likely leave the product susceptible to quality issues.
In many markets, and indeed relationships, customers are less-forgiving regarding crashes and bugs vs. believing “in the vision” of what a product could be. That is, if customers are trialing a product, a feature-filled product with several bugs can be hard to use. Any feedback received will likely be around the bugs themselves.
Instead, the advisable route would be obtaining feedback regarding user experience and desired features – a well-built product with limited scope. User feedback would then lean towards “asking for new features” – the market pulls the startup in a direction with demand and products aren’t over-developed.
How could you argue features could be valued over quality? How else could stringent facets like timelines, budget, and the like be mitigated? What conditions would customers be more forgiving regarding quality of a new product or service?
I wish we had tracked user engagement better with Body Boss; though, I knew where coaches were getting stuck and why they weren’t experiencing the value of what we built. I have a list of 85 schools who trialed Body Boss within 14 months, but only converted 16%. To boost conversion, we added features… Whoops!
We built several features that did lead to conversions and got us closer to product-market fit. That is, we built critical workout features that coaches needed. However, we also added features that didn’t lead to conversions like Pods – ability to track multiple player workouts with a single device vs. a one player, one device before. Coaches were really impressed with Pods and it led to several trials, but not to conversions.

Body Boss Pods on the tablet and smartphone
Why didn’t Pods or other great features not lead to conversions? Simple – the coaches never got to the point to use Pods.
What we built and why we built, is what entrepreneur Joshua Porter calls the “Next Feature Fallacy” (see: The Next Feature Fallacy).
In retrospect, the major hurdle of user/ coach engagement was building a workout program. We had improved the experience several times since v1.0; however, most fixes were band aids, and didn’t solve the problem.
So to use the new Pods feature, coaches had to build a workout program. Except, if coaches were having issues building a workout program, then they never got to Pods. 
Instead of building new features like Pods (a nice-to-have), we should have focused our efforts on user experience and helping coaches get started with Body Boss. Once we got coaches using the system, we could then track engagement metrics and tested the adoption of features like Pods.
What else could we have done to address the engagement issue? How have you developed features that consistently added value?
First foray into iOS and LEGIT programming, and it goes swimmingly well… even if it wasn’t as “simple” of a start as I could’ve made it.

Since August of this year, I’ve been expanding my horizons and challenging an area that terrifies me – learning how to program. Okay, well, I’ve got some experience in programming including JAVA (long, long ago), Ruby on Rails, etc., but nothing really spectacular and for “mass consumption” except for maybe some SQL and VBA from consulting work. My experience in Ruby on Rails goes just a little farther than the One Month Rails course I took back in January. However, it never really stuck with me.

I found that I needed to root myself with three foundational questions that would give me a reason for learning (my WHY), a vision to focus my learning and achieve sustainability (my WHAT), and a way to begin (my HOW). That’s where the following three questions guided me.

Question 1: Why am I learning to program?
Like many idea-people, I have a long, long list of ideas of things to try/ build in terms of potential startup ideas. My list has started to get long in the tooth. Some of the ideas are similar to what some startups are now doing very well and/ or raising quite a bit of capital. As they say, ideas are worth nothing… it’s all about execution. However, with the market where it is being a highly developer world, it’s sometimes hard getting/ inspiring/ motivating developers to help build ideas without money, and I’m not a developer by trade. I’ve talked to a few other entrepreneurs and they share the same sentiment – good developers are highly valuable resources with no shortage of demand. 
I remember talking to one of the co-founders of Hired.com a few months ago, and he mentioned how he and a couple other great developers met one day to talk about possibly working together. After a couple meets they moved into a house near the Valley. They churned out projects weekly. They weren’t bottlenecks in their aspirations, but I was in mine. I don’t want to be limited in achieving what I want to. If I believe in myself and what I’m doing, then investing in some learning should be well worth it.
So, that’s what motivated me to really learn and become a developer — a reason for doing. I’m never going to be an extraordinary developer like the Body Boss guys (or designer), but I’ll know enough to be dangerous and launch ideas. If any of them stick, then great. I’ll then hopefully raise some capital to then find a more technically adept partner. Of course, there’s got to be some time to develop the ideas before churning out the next one. Anyways…
As an ancillary (but big) benefit, I’m hoping more experience with programming will make me a more adept entrepreneur and team member. I’m still figuring out my best skills and roles (product management, sales, marketing, general business development, PROGRAMMING?!, etc.). Right now, I like to be a generalist and my breadth of skills allows me to adapt quickly and effectively; however, I think strengthening my technical shortcomings will be valuable in an age of growing technology either by understanding customers’ needs, communicating with technical resources, or exploring new entrepreneurial opportunities.
Question 2: What am I starting?
Now with a purpose, I wasn’t sure what to begin or even what would keep my learning going. I needed to build something that resonated with me to give me short and long-term visions and goals.

After a brainstorming session in July, there was an interesting idea to help parents better buy and sell used kids goods. This was the inception of Dee Duper, the idea I’ve been building out since August. Though, to start, I wasn’t sure which way or where to start. Kick in some of my experience from the past, and I did customer discovery vis-à-vis a survey (using Google Docs) to answer some questions and test out some hypotheses.

Okay, you’re about to see some questions, responses, and charts from the survey – 48 parent respondents. Let me preface the results with this: I know, in retrospect, that the survey can be better structured, worded, and more MECE. I’m comfortable showing the results, however, knowing full well the responses are not “scientific”. The answers provide a good vane for the direction I should head, and as an entrepreneur, I don’t need exact measurements to get started. These examples should also serve as food-for-thought about how to make your own surveys more robust. Again, every iteration you do something, look to improve. I’ll write a post in the near future (Jan 2015?) on how I would improve my survey in retrospect.


Focused my survey on parents with 48 respondents.
Aside from “None; N/A” and “Other”, major problems of existing resale channels include Search and Trust.
One of my major hypotheses was that payment of goods between parents was a big headache. However, I learned that overwhelmingly, the major pain points revolved around search and trust. Okay, that changes my potential development roadmap, but where to start programming? A few more questions were needed via the survey…
The computer is still dominant for users followed by the iPhone. Though not focused on which device is used for online shopping, this still motivates me to build on iOS as the mobile app first.
Survey respondents were overwhelmingly users of the iPhone. So that’s where I was going to dig in for my first technical entrepreneurial foray – iOS! Yes, ‘Computer’ was actually the top device, but I knew/ wanted Dee Duper to reside mobile (native) first as an MVP (phase 0) especially given other outside research from Black Friday shopping, UPS datapoints, and my observations of target consumers on channels like the many “Mommy Exchanges” on Facebook. Phase 1 would include a web app, likely built on Ruby on Rails.
I have such limited experience in Apple’s Objective-C language, and with Apple’s announcement of its evolution in programming language, Swift, I decided to start with Swift. The syntax looks cleaner and if I went far back in my memory, it’s more similar to JAVA, I think.
User sentiments to the apps I was most interested in. In retrospect, I could have included other popular apps such as Pinterest
Through the customer discovery survey, I also learned what apps and platforms users used on a daily basis and their thoughts on the quality of the popular apps today. All this allowed me to go beyond just building on Swift but also help me think about design and usability as well as potential integrations. In my case, I’ve learned that removing barriers to sign up and get into an app is critical, so leveraging Facebook’s login was going to be my way forward.
Question 3: How did I start?

With limited experience in programming for the masses and a plethora of options and courses to learn programming, choosing where to begin and with who can be daunting. Luckily, when I started in August, Swift wasn’t talked about too much, yet, so I had limited options. I decided to get started with Treehouse.com. I ended up shelling out $99 for a Swift course. Treehouse did a good job of showing me the basics, and getting me used to the syntax. However, the course I took wasn’t a great one to learn how to build what I wanted to build.
Instead of spending more $$, I decided to explore free tutorials, and found some videos on YouTube by Brian Advent. This was actually really great because Brian also talked about not only Swift, but integrating a mobile back-end (with Facebook’s Parse). I hadn’t thought about what, where, and how to host the database to run Dee Duper, yet. He had some videos that explained how to build a Twitter-like app, so that’s where I would work alongside him through several videos, and then go off adapting what he taught to Dee Duper.

Starting from there was a lot of trial and error. I won’t hash this out because there’s quite a bit, but I’ll write posts in the very near future about my lessons. It’ll be on-going so stay tuned!

As a take-away for you, there are a TON of courses all over the internet including physical classes you can take if you so have the time and money to pursue. If you’re like me bootstrapping everything, there are plenty of free tutorials that will get you off and running quick.

Where I am and where I’m going…

Last Monday, December 1st, I actually received word that Dee Duper was approved for the Appstore! First time submission, first time approval. Pretty stellar stuff, I think. It took a while, but it’s come together pretty nicely.
Funny enough, while building Dee Duper, I’ve also picked up some part-time consulting to fill the coffers and get some mental stability, I’ve been thrust into building all sorts of models in VBA and even asked to do some SQL to build data cubes and algorithms. All of a sudden, I’m finding myself mixing up programming languages having taken on all sorts of technical roles. To the point above about why I wanted to pick up programming, I’ve definitely found myself much more marketable and able to swing into all sorts of different projects where others couldn’t. Plus, the added analytical side of programming has given me some creative ways of approaching other more strategic consulting projects.
Back to Dee Duper and my programming… Dee Duper just launched in the Appstore, but honestly, I haven’t marketed it at all. This is where a lot of work and effort will come into play. What I need to do now is find initial traction, and gather their input. I did my beta testing with some users throughout development, but now that the app is more widely available, learning will be critical.
You can now find Dee Duper in the Apple Appstore!
From the feedback, I hope to find what works, what doesn’t, and the missing elements of Dee Duper to achieve product-market fit. I’ve got a roadmap of what I want to integrate next with Dee Duper including geo-location, saved searches (alerting you if something is posted that you’re looking for), favorites, etc. For now, I’m eager to gather feedback of the MVP of Dee Duper before I go building a bunch of features nobody wants.
I’ll post some quick lessons since I started programming in the next month. I’ll also start sharing some technical posts including how I’ve implemented different features, headaches I’ve come across, etc. The Swift developer community is still very young, so the help library is sparse. Hopefully, I can help build that up.
What questions do you have about how I got started either with Dee Duper or programming? Are you someone who wants to code, but hasn’t stepped into it, yet? What’s holding you back? Or, if you did start coding but not a coder as a full-time gig, why/ what are you coding?