D. Shultz- Product Founder, Faktor
Coming into PM101 with feedback from two customer pilots and a small amount of revenue generated over the summer, I thought that Faktor was in a good place to start developing an MVP. To me, the product would be an end-to-end hardware development solution that would connect users with all the factors of production (designers, engineers, and manufacturers) and manage the hardware development process for them. And, I thought it would be a quick(ish) win -- we just needed to start building the product. What could go wrong, right!?
What I soon realized was two-fold: I did not have enough customer needs data to draw meaningful conclusions (for example, we couldn’t tell if the customer success over the summer was random or if its drivers were scalable), and the scope of the product I was seeking to design was vastly too large to build and test in an efficient way following lean methodology. This led our team back to the drawing board to follow a true product management process from the beginning. Through an iterative series of interviews, low-fi tests, and wireframe tests, we refined our understanding of the customer and changed our product strategy.
The product strategy for Faktor now focuses on specific customer segments and specific step in the hardware development process. The target customer segments are (1) individuals / independents developing hardware products for the first time, and (2) small but experienced teams accelerating a business focused on a hardware product. The specific step in the hardware development process we prioritized is finding and communicating with the best hardware designers and engineers. We believe that by starting from a narrow focus we can observe our customers and learn what their next most important need is, and continue to build our product from this base in the most efficient way.
This process of changing our product strategy speaks to the attributes I have come to understand great products have. I would boil them down into four categories:
Every element of the product serves a need. There are no features that aren’t critical to solving a customer need. Features have been carefully prioritized and hesitatingly added.
Each of the needs that are served are significant needs. In other words, the product solves something important to people, something that matters to them. If the product is solving minor needs, then I don’t believe it is a great product.
Intuitive and easy to use. The product requires the user to expend virtually no brain power, and a minimal amount of time, to learn how to use it and understand its value.
Constantly improving, evolving, building. The product enables the product manager to easily observe users and hear their feedback, which is used to improve the product. This means deleting features, adding features, improving UX, etc. A roadmap to achieve a long-term product vision is adhered to, but is dynamically updated according to new information from customers.
Another key ingredient in building a successful product is effective team working relationships and processes. I believe our team worked together exceptionally well: at a fundamental level, we were open to giving and receiving feedback, learning, and being flexible in our expectations of and desires for the product. This allowed us to efficiently identify root causes of results in customer interviews and tests, and identify the best solutions. Additionally, we were able to use each other's time efficiently.
I believe our discovery process was strong in the research, solution generation, and wireframing phases. Where I think our process could have been improved, though, is in the testing phase. It is hard to know precisely when it’s right to run another test versus when it’s right to take a risk and move forward with a decision that may not have fully statistically significant customer validation. In fact, this is probably the most common, and difficult, type of decision made by a product manager! On balance, though, I think we could have been more systematic in our approach to testing. I do believe we did a substantial amount of testing that yielded valuable insights, but it was somewhat inconsistent. What I plan to do differently going forward is to establish a systematic, recurring schedule of customer tests ahead of time, and the wireframe updates made between tests will automatically be included in the next test. This would ensure we have a consistent, recurring flow of customer feedback!
I learned a couple of great lessons going through this experience. First: the power of truly treating product management as discovery. When you watch customers and listen to what sucks for them, what pains them, what elates them, what thrills them, what makes them cry, the precise solution to their problems kind of falls into place. It is easier than it seems (at least to me!). The second: a tremendous amount of waste can be avoided by exhaustively testing cheap, lo-fi prototypes. Finally: the value of 10 minutes of feedback from a customer can exceed the value of an hour of internal debating at the white board!
The lessons I’ve learned in this semester have completely changed my understanding of the role of a PM. The PM is not simply a conduit for information to flow from sales to engineering. The PM has to balance a long-term vision and strategy for the future of a product with the day to day discipline of an efficient product development process. The PM has to speak multiple languages in order to educate, influence, and convince groups of employees coming from dramatically different cultures (sales, engineering). The PM has to know when to shut up in order to hear nuanced customer feedback. The PM has to negotiate compromises where people often don’t get their way. Ultimately, the PM is responsible for the success of the company!
The daily challenge, platform for creativity, balance of strategic vision and short-term execution, and fast-paced learning that comes with PM work has made me really excited to get into this field. I view it as a fit with what I’m good at and what I enjoy doing. I think the discovery process fits with how I approach problems: first understand, then design (vs. build first, then find a problem). I see a long future at Faktor, full of product improvements and new product development, so I am looking forward to many more product management opportunities!