A Product Manager’s First Solo App

Prior to attending Fullstack Academy, I had spent my entire professional career as a product manager working at various tech companies. I initially fell in love with the role because of how it was the intersection of so many different but relevant disciplines (data analysis, research, design, engineering, marketing, cross-team collaboration, etc.) and grew to love it even more moving from company to company and seeing all of the different ways to tackle problems and capitalize on opportunities.

However, at some point last year I had a realization: my favorite part of my job was building products and, as a non-technical PM, I couldn’t build an app myself. This is why I stopped everything I was doing and pursued an education at Fullstack Academy; so I could learn the skills to do what I loved most.

Like most product managers, I’ve kept a laundry list of applications I’ve wanted to build over the years and couldn’t wait to get started building something once the course began. This is why I began working on my Fullstack hackathon project two weeks after the program kicked off. But I’m getting ahead of myself — let’s go into what I decided to build, why I built it, and the framework I was going to use in the development process.

For as long as I can remember I’ve loved playing fantasy sports. I even launched a site (DraftSmarts.com) in 2014 that uses an algorithm a friend and I developed to help people pick their fantasy teams. However, that algorithm only worked for traditional fantasy drafts (picking one player at a time in a consistent order) and over the past couple of years I’ve grown fascinated with auction drafts (all participants bid on players to comprise their teams). So unsurprisingly, I’ve been wanting to build an auction draft tool to tell me the maximum bid I should place on a given player at any point in a draft.

Following good product management practices, I started two years ago by creating an MVP in Microsoft Excel using a linear solver plug-in. While this was largely effective (teams I picked using the model did well for the most part), using Excel had its drawbacks, primarily the model’s static results (it needed to be run several times before communicating a maximum bid), slow run time calculating a result, and inflexibility for interesting customizations that a programming languages would allow me.

But before diving in and just building something based off of these pain points, the inner PM in me kept saying I needed to map out my development journey a bit further, including success criteria, user stories, and a development and testing plan. So starting with success criteria, I decided to break it down into the following categories with corresponding goals:

Product success

  • An average grade of A from Yahoo’s draft ranking system

Design success

  • Usable for all fantasy football players

Code success

  • No bugs!
  • Scalable to other fantasy sports
  • Clean code

Note: one theme of goals I left off were metric centric goals (acquisition, activation, retention, etc). This decision was made considering this was supposed to be a hackathon project and I do not plan on turning this app into a business in the foreseeable future.

The user stories I wanted to tackle for my first MVP were the following:

  1. As a user, I want to know the max I should bid on any player during the auction draft based on what’s already happened and what’s projected to happen
  2. As a user, I can remove players drafted by other teams
  3. As a user, I can draft players to my own team

And finally, I decided my development path would consist of the following 5 phases:

  1. Creating a console-based proof of concept
  2. Building a web scraper to aggregate data
  3. Testing part I — the console product with the new data
  4. UI and additional features
  5. Testing part II — the complete app

So let’s get into it!

Phase 1: Console based proof of concept

I deemed the hardest and most essential part of the project would be finding the right linear programming module (a library that essentially runs the knapsack problem) and tailoring a dataset to work with it, so why not start there? Luckily I found a linear programming library with good documentation pretty quickly and was able to get it to spit out an optimized lineup based on projected points and average auction prices from 2017 about an hour after starting work. From there, I was able to build the right functions to hit my user stories (figuring out a player’s max value and drafting/removing players) and boom, we had a viable proof of concept!

Phase 2: Data aggregation

The next step in reaching an end product was to start plugging the most recent data into it. Seeing as I would need to do this on a repeated basis based on injuries, team transactions and player suspensions, it made the most sense to make the investment in building a tool that I could run whenever the application needed a data update. This is why I decided to build a web scraper that I could run on demand using Puppeteer, which uses Chromium and basic JS DOM querying commands to return data from a website. The scraper would first go to each website I needed to pull data from, save it, and then merge the data into a master file that could be read by the model created in phase one. While this took a little while to build, I soon enough had my basic MVP complete and ready for its first round of testing.

Phase 3: Testing the proof of concept

And what better way to test our console app than to run it in a practice draft? So that’s exactly what I did, and the best part was the result: an A+ from Yahoo’s grading system!

While it was a pain to run the app in console during a draft (lots of typing and, surprise, not the most friendly UI), this was great early validation for our application.

Phase 4: UI and additional features

Now we had a working application, but as mentioned above, it was far from perfect. This is why building the UI for our app was the most logical next step and by far the most time consuming.

At this point the inner PM in me was also shouting, “based on what we learned from our console testing, we need to edit our user stories! And we also need a wireframe!” so I went back and added the following user stories to our list:

  • As a user, I can browse a list of available players in the draft
  • As a user, I can search for a player
  • As a user, I can see players other teams have drafted
  • As a user, I can see players I’ve drafted

Taking all of this into account, I was able to produce the following wireframe:

For the front end, I went with the react/redux combo we’d been taught at FSA, Semantic UI for styling and managed to keep all of my components very generic so they could be re-used for other fantasy sports (based on our original goal of scalability). After lots of time spent developing and bug squashing (to hit our ‘no-bugs’ goal), we finally had our finished application, including a couple of extra features I threw in for good measure:

Phase 5: Testing the final app

Now that we had our close-to-final app, it was time to run through all of our validation criteria one more time:

An average grade of A from Yahoo’s draft ranking system

Once the app was complete, I took it for 3 more spins with Yahoo’s practice drafts and received 3 more A+ grades!

Usable for all fantasy football players

Once the app was deployed and in a close-to-complete state, I sent the link to a few of my close family and friends and told them to play around with it and even try it with a mock draft if they felt so inclined. Through this I was able to get good feedback (such as it’s unclear how the players are ordered and there’s a little bit of a lag on one of the buttons) that I plan on using for future iterations of the product. However, there were no signs that it was unusable or unfriendly, so a check for this goal too.

No bugs!

Throughout development and testing I was able to uncover a few bugs, all of which I squashed as soon as I found them. Additionally, in user testing nobody was able to find anything that would classify as a bug, so another box checked!

Scalable for other fantasy sports

As mentioned previously, by making the front-end simple and reliant on the model generated, all of the UI is reusable for other sports while a good portion of the back-end is too (save for the sport-specific aspects of it), which is the most I could ask for from my app for this goal.

Clean code

This is probably the most subjective goal I had, but I feel as though I did a decent job here. The web scraper definitely needs a lot of refactoring, but the front end react components are in very good shape (smaller than a bread box as I like to say), and I even created a special file for my redux store that includes only helper functions, which is largely helping keep the size of my store. All in all, I give myself a 5/10 here.

Considering all of the grades, I believe I did a pretty good job in terms of hitting the validation criteria for my first solo project. Of course the app isn’t “finished” as applications never are, but it’s developed and tested enough to be considered a useful fantasy sports tool.

Most importantly, I believe the biggest takeaway from this experience was that my skills as a PM and developer are extremely complimentary, not that it was a surprise they would be but just how much they benefited me throughout the process of creating my first app. Furthermore, there are certainly more levels for me to reach combining these skills and I can’t wait to keep working on them!

Project link: https://fantasy-auction-helper.herokuapp.com/

Github: https://github.com/Auction-Draft-Helper/app

Presentation: https://youtu.be/9HwloUDZKzo