#DeskJockeyChronicles

View Original

Now Introducing: Pawparazzi - A mobile app for dogs and their owners to take better pictures

Pawparazzi's mission is simple: We want to help dogs and thier owners take better pictures.

The journey from ideation to launch was much longer than I expected, from being inspired by my own dog, Moose, developing the app in collaboration with a friend and freelancer from Poland, to finally launching in June.

It was not easy; we experienced highs and lows and learned some lessons along the way. Here are a couple of important milestones that brought us to our launch day.

From ideation to wireframes

When I first tried out the sample sounds with Moose, he came running from the other side of the house. #WINNING

By the end of the first week, he would barely lift his head when I played the sound. 🚩🚩🚩

The lesson learned from this phase: Do the right amount of thinking on the requirements. In my day job, we have gotten in the habit of thinking about our websites and customer portals as products. Incrementally delivering functionality to deliver incremental value/revenue. This leads to defining an MVP and getting to launch with the focus of optimizing after you launch.

In this instance, my goal was to see and experience the process of getting an app live and then watch the ad revenue start rolling in, of course. 🤑

I am not saying to develop your 5-year roadmap, however detailing out what you want the product to do in the short and long term will provide you and your developer a vision to build upon. Thinking through and enumerating your requirements will help communicate your vision and hold your developer accountable.

Wireframes to prototype

The Pawparazzi dream (and our $1 MRR) would not have been possible without Brian, a former co-worker and friend who has "hands-on keyboard" development experience. When we first connected on the project, I thought we were getting our former "day job" band back together. In that band, our typical set would include working together to define the technical requirements and then Brian developing the app. However, the timing was not great as had he several life steps in motion (Moving, baby, etc.). Not the best time to take on a side project.

Lesson learned from this phase: It's about the people. If you are not partnering with the right technical co-founder/developer (personality fit, knowledge, the ability to solution with the goal of delivering a quality user experience), you may struggle to realize your vision.

Additionally, you need someone who will act as an effective product owner who can represent your customer requirements and market insights. This is the role I played, however as we both were proud of the dogs we count as family, we had some healthy discussions on the experience we wanted to create.

Together Brian and I went with our wireframes, desired user experience, and technical requirements to solicit quotes from several freelancers on Fiverr. We selected a developer based in Poland based on the following factors:

  1. his portfolio of past work

  2. his ability to communicate clearly

  3. and a combination of the price/turnaround time

Working with our newfound friend in Poland, we produced a clickable prototype of Pawparazzi. While it was not much different from the wireframes we had in hand when we walked into the engagement, but it was great to see our idea start to take shape.

Prototype to Minimum Viable Product (MVP)

With the prototype in hand, we identified two requirements that had slipped through the initial cracks. These requirements were so fundamental, I had assumed they were part of every application just based on the features on the phone. In retrospect, I realized I also assumed that the developer knew that we needed the app to do this functionality based on the purpose and value statements.

Lesson learned from this phase: You know what happens when you assume.

If you want the functionality included in your app/project, you have to explicitly state. That said, this was the first of several instances throughout the project that drove home the message "You get what you pay for" in terms of developer capabilities and client experience.

These two features increased the cost of the application by ~25% and kicked off a spiral that took what was supposed to be a three-week project and turned it into a 3+ month slog. This led to large frustrations, misaligned expectations, and several failed ignitions at “launch week".

I had tied payment of our agreed-upon total project price to the accomplishment of milestones within the project however these milestones/payments were not tied to calendar dates. I had assumed the project would be completed within the three-week window. You know what happens when you assume.

An equation showing this lesson learned:

Project plan + milestone deadlines + milestone payment + reward for ontime + pentalty for slippage = Managed expectations

Launch

After working through a seemingly never-ending process of feature/bug whack-a-mole and less than stellar launch checklist we "shipped" in mid-June and the rest is history.

The app paid downloads nor the ad revenue is enough to enable me to retire. Sadly the revenue from each incremental user is not enough to justify paid advertising which limits the growth tactics.

This leads me to my last learning: Think through the revenue model and growth tactics before embarking on your journey. How you are going to make money? How you are going to attract the users to drive this revenue? My goals for this project were (1) to be able to say I have an app on the App Store and (2) to learn from the process but I would be lying if I wasn't a little disappointed in trickle of ad revenue. This story isn't over. 😉

Is it great? No. Did this plant the money tree in the backyard? No. But we got it done on a razor-thin margin, on the side, and learned a few lessons along the way.