I left my ... iPhone(3) at Juniper Square

FYI, I'm known as iPhone(3) on zoom
In September, I left Juniper Square where I joined as a product manager during the earliest days of covid. At the time, I had recently left frog design where I spent five years consulting on digital and physical product design.
Now was the time to put theory into practice.
The difference between consulting on and building products is stark. You must sift through the noise of feedback from every direction, resolve tradeoffs that seem impossible, deeply understand the capabilities and limits of inherited systems, endure the daily grind required to build enterprise grade software - all while continuing to motivate and inspire engineers. For this experience, I am grateful and enlightened. While I will take away many lessons from my tenure at Juniper Square, there are a few “Adam-isms” have left a lasting imprint on my thinking:
The importance of choosing the right butter
Adam would always use this (very far-fetched) analogy of sending a friend to go to the grocery store to pick up some cultured butter to illustrate making cost decisions in product development. The takeaway is that sometimes cultured butter is not readily available at your local grocery store. If this happens, should your friend drive over to the next grocery store to keep on searching? Do they go as far as making their own cultured butter? Or should they just call you and ask - is it possible to settle for regular butter? In the context of a resource constrained startup, this is a cautionary tale about the critical communication between product and engineering around making tradeoffs during implementation. Sometimes cultured butter isn’t worth the extra time or money it takes to obtain it - so settle for regular butter and make sure that everyone on the team knows that regular butter will do the trick.
Always think three steps ahead of the customer
It’s crucial not to treat customer and user research as outsourced idea generation. Customer research serves as a means to an end, not the end itself. Just because a customer explicitly suggests how a product should function doesn’t mean we should rigidly follow their suggestions. Adam consistently encouraged our product team to think beyond the immediate customer request.
It is the product team’s responsibility to look three steps ahead of what customers are asking for and draw upon our unique knowledge of the underlying technology/systems, the company’s future roadmap, and of course customer empathy to create solutions that anticipate needs. Customers provide the context and inspiration - not the solution - that’s our job. This approach is harder than to just listen and build what the customer asks for because it is often riskier from an adoption perspective and sometimes may have greater execution risk. However, it is the most creative and rewarding aspect of the product development process.
Find free stuff
Software development offers the advantage of reusability — once built, software can be used and scaled at minimal cost. Product managers should always be considering reusability in all forms - UI, features, data model, APIs. They should always be thinking - how do I maximize the business and customer value of what we have? This is a major difference from how we thought about things at frog where we were often engaged for blue sky thinking.
However, finding opportunities of code and product reusability isn’t always easy because the allure of building something new is very tempting. Building from scratch is easier and in my opinion more fun. Extending and reusing comes with significantly more mental overhead (i.e., learning a system that you didn’t create), can come with considerable risk (i.e., extending a system can have considerable “blast radius”) and sometimes can end up costing more than building new. The balancing act between extending the existing and building new is an art that I have only just started to scratch the surface on.