Some Thoughts from the Intersection of Product and Development

Building software is hard. The cloud makes it easy. But it’s still hard.

That was the first thing that came to mind, having taken a breather from coding over the last few weeks. I have been building out a small MVP, and I recently established core functionality. Sure, there are edge cases, bugs, and issues of stability to address, but I would argue that even a minor milestone offers a ready seat for reflection.

Some background. I learned to write C and Java at a university. I wrote some sample apps and messed with code puzzles. Although I enjoy it, it is a recreational art second to my focus on Product Management. That requires thinking along these lines:

• Why are we building this?
• Who is the user base? Their demographic? Skill level?
• What are the risks? Assumptions?
• What is the problem? Do I understand it enough?
• …

There are a litany of Product Management exercises to arrive at some understanding here, and if your purpose is to make money, you’d be well-advised to run through them many times and many weeks before writing a line of code. On the other hand, I think tinkering is okay too. If an idea pops up and you just want to build it, I say build it.

In my case, I wanted to let hikers and backpackers put dots on a map corresponding to primitive campsites and water locations. I would create a web app to solve a problem I have when I go backpacking. How much water do I need to carry? Where will I stop and pitch a tent for the night? I decided early on that I would dispense with classical Product Management and avoid the whiteboard, the empathy maps, and market research. I decided to stop thinking about thinking, and I started throwing shit together in AWS.

Being relatively new to AWS, I arrived at this outline after a weekend or two of research:

• Storage: RDS (MySQL)
• Front End: S3 Static Hosting (HTML + Bootstrap + JQuery / Javascript)
• User Management: Cognito Javascript SDK
• In Between: API Gateway + Lambda (Python)
• Mapping: Mapbox

Coding all this out felt at times like digging a ditch with a spoon. A background in old school programming doesn’t prepare one for networking, integration, and security. The syntactic shifts caused by working in Python / JavaScript / MySQL further reduced my efficiency. In addition, I worked through various undocumented hiccups with running Python in a Lambda environment, some fits and starts with API Gateway’s mapping templates, yada yada. Eventually, I ended up with something that worked. Let me introduce Campsite Collective:

(I want to give a lot of credit to Derek Piccola. He replaced my woefully insipid Bootstrap with what you see here.)

It will be a few weeks before I deploy this app — whatever that means, since I’m still deciding on what scale, to whom, and what my expectations are for it — but the user flow is more or less cemented:

• By clicking “Register” from the home page, a user creates a profile.
• Provided a user has confirmed their email, they can right click the map and add either a campsite or a water source. I save the latitude and longitude.
• Whenever the page loads, it fetches all campsite and water locations submitted by users. You don’t have to be logged in to see the campsites.

Building can be instructive on its own terms. However, the process exposed me to some larger lessons that are worthy of discussion.

You can do it all, at least for a while

In the early days, it’s probably enough for a founder to do, well, everything. With one person, there’s one vision. You can code and QA and design all on your own. Yet every added feature multiplies the complexity, increasing the demand for processes and people. That means putting the vision on paper and communicating it.

Speaking of which, it was only in explaining this project to others that I realized how compartmentalized the idea was. Hence the reason Product Managers obsess over roadmaps and Venn diagrams and user stories and presentations. Even if you’re just tinkering, you should still be able to tell the story of what you’re doing and why.

Technical debt is frighteningly easy to create

Driven by the desire to “get it working”, I didn’t assess my work very often. For example, when my Node Lambas failed, I pivoted to Python successfully. Rather than research why they didn’t work, I scrapped them along with any opportunity for learning. A few other complaints: my error handling could be improved, my early CSS was a mess, and my API Gateway could use some standardization. Some of my Javascript doesn’t follow good architectural practices. Not good. Also, I have no clue if this thing will scale to a large-ish user base or go over like the Hindenburg.

I plan to go back and review the work piece by piece, mainly for the sake of understanding (and perhaps documenting?) what I did.

Know when enough is enough

Here, the Product Manager’s discipline pays off. In pitching this project to others, I was overloaded with various ideas for improvement. (Whoa! It took me one afternoon to get email verification working — I haven’t even gotten a dot on the map.) I would argue that it’s much better to have one or two rock solid features than it is to have thirty that are half-baked.

Regardless, you do eventually entertain other features (especially after a milestone). You envision other integrations that would make this product cooler than it is. Why? Because the developer side of your brain says, “It’s lame … It only does two or three things.” The PM side says “Yes, but that’s exactly what I wanted it to do.” Listen to the PM side.

Good design is difficult, too

Switching from Python to Node to vanilla Javascript / JQuery wasn’t nearly as bad as working with CSS. In classic programming, data structures, loops, and control flow comprise universals that exist across languages. Ignoring language-specific details, you can get by with a syntax guide and some code samples. CSS is another thing entirely. I lack a fundamental understanding of it, which meant I had to bend the initial design to my very limited skill set.

Again, plenty of credit to Derek Piccola who has mastered this arcane subject and reworked Campsite Collective.

Look at those Semantic modals!

I also thought much about design in a holistic sense. Forget about design principles, notions of pattern and contrast; these could be debated for hours. I simply think a good artist has the rare ability to introduce novelty in a way that feels familiar. In plain terms, I know good design when I see it, and my initial version of Campsite Collective was not good.

(Take a look at these websites. I don’t care much what they’re for, only that they’re visually engaging and very different: Heco, WE AIN’T PLASTIC.)

You can do pretty much anything in AWS

Do you recall that scene in Gladiator when Maximus and Juba return to Rome and lay eyes on the Colosseum? Juba says, “Have you ever seen anything like that before? … I didn’t know men could build such things.” If you have the requisite knowledge to appreciate it, AWS inspires the very same sentiment. Not bad for a company that a started as a bookstore.

Next steps

That concludes some early thoughts on the challenges of Product Management and Development. I plan to follow up as I get closer to launching Campsite Collective. Stay tuned.