Lessons learned from a year of product
Product is difficult. Heard that before?
There are ways to do approach product development, in a rapidly evolving industry, sometimes it can be hard to figure out which way is the right way for you. Have you ever found user stories gathering dust in your ever-growing product backlog as you slowly lose focus on why they were even there in the first place? Have you ever felt like you’re being reactive to issues springing up left right and centre, fighting fires one day to the next? Do you find yourself asking “how high” when your clients say jump? If any of this sounds familiar then I can guarantee one thing. You’re not alone.
When I started running product at OneUp I noticed these issues, among others, cropping up on day to day basis. I started leading product in 2020, around a year ago. Back then we didn’t even have an official product department. We had 2 devs, me included, and a CTO. That was our product resource. Feedback flooded in from customer success and support which slowly but surely filled up the backlog with an ever-growing list of bug and user stories. Our backlog had become a graveyard full-on unscoped and invalidated ideas, in some cases we had user stories that had been sat there for well over a year. No matter how hard we fought to reclaim dominance over the backlog new requests and issues would come flooding in. By the time we got around to addressing the dusty user stories, we had lost so much context that we’d basically forgotten why they were there in the first place. The issue was, we had no process for how to do product properly. But what does properly really mean?
Today I am going to share with you a candid, down to earth story about the issues I faced at OneUp and how we overcame across them. We’re a small company, 7 at the current headcount. We expect to grow to around 14 heads over the next year. We have a tech department consisting of three people, myself, another dev and the CTO. Why is this important? Because now you know whether this article is going to be relevant for you or not. One of my biggest pain points over this past year has been reading countless product resources that fail to capture their target audience. Product process for a small startup is vastly different to product process in a VC funded unicorn superstar with a seemingly infinite amount of product resource behind it. That being said I’m sure there’s something here for everyone, so welcome 🙏🏼.
I’ve summarised my experience into a set of rules, which, given the power to travel back in time, I would have bestowed on younger product Alex’s self.
Rule #1: Stop thinking, start executing
This was me. Not the monkey, that truly would be a ✨glow✨ up. This was me back in March of 2020 after deciding I wanted to formally make the switch from dev to product. I’d sit for days constantly thinking about product. What is product? How do I do it? Wait, how many types of user interviews are there?! It’s very easy to fall into a deep product hole akin to those YouTube holes one tends to end up in at 2 am. The field of product management often feels like a relatively new field yet its origins predate modern tech as we know it all the way back to the 1930s. Although modern product management solidified itself in the birth of tech in the late ’90s and early 2000s it’s roots run considerably deeper. A lot of work has been done to understand how to successfully run a product at a company and trust me when I say there are a lot of resources out there, too many even. It’s very easy to get bogged down with challenges that you simply don’t have as a company. Like with a lot of things in product, it’s all about focus and how we apply it.
You don’t know what you don’t know.
I’m somewhat of a perfectionist. That’s not a flex, it usually incarnates itself in me spending way too long thinking about the multitude of way to do something and not enough time doing the dam thing. I spent hours on Udemy tutorials and medium trying to figure out every minute detail. I’m not saying it was a waste of time, however, I can safely say that I have learnt a hell of a lot more from simply scrapping the theory and just getting on with it. Learning theory is great, I’m not discouraging that. However, there comes a point where theory can bog you down. In product, we promote the practice of rapidly iterating to learn from our failures. We need to recognise that this process should also apply to our own learning. So by all means, do a little research and don’t skip out the planning phase, but don’t be afraid to just do it (please don’t sue me, Nike).
This brings us smoothly onto my next rule…
Rule #2: Be comfortable with failing
This may sound cliche, that’s because it is. However, do you know what most cliche sayings have in common? They’re usually grounded in some form of truth, otherwise, they wouldn’t be common. In development, nowadays we tend to develop in an ‘agile methodology’, albeit to varying levels of success. Agile promotes the rapid production and deployment of code, the ultimate goal here is to push stuff out quickly so we can learn from our users quicker. Gone are the days of 3 year turnaround times on pieces of software. I’m a big fan of this approach personally. The sentiment of agile applies well to the product process as well.
Ship often, learn often
At my company, our product team lives by this principle. But it wasn’t always this way. When I first created the product department I would spend a lot of time considering whether the approach I wanted to take was the right approach. Was I using the correct interview techniques? Was I talking to the right customers? Was I guiding my team in the right direction. This is common. Ultimately you want product to be a success, therefore it’s human nature to try and ensure that success by being cautious. Ultimately I learned that it was simply more efficient to just try, fail and learn then it was to spend weeks doing upfront research.
Obviously, the last thing we want to do is introduce bugs, piff off users or have features completely flop. However, there is a healthy mix we can achieve. It is not possible to know ahead of time whether a new feature you’re introducing will be a success. You can collect as much data as you like, but until you let it out into the wild, you will never know for sure. Over the past two years, we’ve learned this the hard way. We’ve missed the boat on some features because we spent too long with the solution in front of us as opposed to the people who really matter, your users.
Don’t be afraid to run with your gut. And if you’re a leader of a product company, try your hardest to create a high trust environment. You want your people to feel comfortable with failing. For every 9 failures, you could have one success that could revolutionise your business.
Rule #3: The perfect approach doesn’t exist
Every company has their standard way of how they approach product. You may have come across Intercoms approach with Job Stories, a personal favourite of mine. However, even with a company such as Intercom, I have to admit that their approach and other companies alike should be taken with a pinch of salt. Why? It’s not because their approach is a bad approach. It’s because their process works for them. No two companies are the same, each has a unique makeup with unique people. The process that you adopt must work for you, not a carbon copy or another companies approach. Don’t fall into the trap of building out product process that doesn’t work for you. You will likely have different resources and priorities than that organisation.
By all means, be inspired, but don’t copy. For example, we recently adopted Basecamp ShapeUp method as our new approach towards product management. Did we implement it word for word? No. Why? Because there were elements that just will not work for us, that’s okay. Take a holistic view of your own process. Where are the gaps? Identify those areas and then research ways in which to fix those gaps. Don’t replace the parts that are already working, there’s no value in fixing something that isn’t broken.
Following rule #2, acknowledge that your process won’t be perfect the first time you try it. It’s important to try new things, but naturally, they will need tweaking over time, it’s an iterative process. At my company, we’re iterating all the time. Only last week we explored Miro’s Product Alignment Document (PAD) for capturing a feature from problem definition through to post-release. We found that parts of the tool worked really well for us, others didn’t. We actually ended up cutting it in half and stealing (taking inspiration) from the bits that we found value in. That’s not to say that Miros PAD was wrong, it was right for them. We only learnt this by trying it out; so don’t be afraid to try new approaches.
Rule #4: Obsess over conversations
Unfortunately in the past year, we’ve not been able to do a lot of the old face-to-face talking. If you’re reading this far in the future, hello from a pandemic 👋🏼. However, truth be told in tech your users are scatted across the world making face-to-face slightly irrelevant anyway. The goal behind the conversation is to gain a deeper understanding of your users and their needs. When I first went into product the thought of talking to customers was really quite an anxiety-inducing experience. What if I asked a stupid question or didn’t know the answer to a question of theirs? I felt like before I could talk to customers I needed to become an expert in their field. This approach defeats the purpose of discovery work. As a new product manager, one of your jobs is to immerse yourself in your problem domain and understand, from a first-hand experience, what pain points your customers have. Knowing less about a field can be used to your advantage as you remove any subconscious bias you may have for a subject.
There’s no such thing as a stupid question
At OneUp, we work in sales and recruitment as a tech solution. Whilst I am passionate about solving problems for our clients, do I find recruitment deeply interesting? No, not really, there are interesting parts to it but I am hardly going to go away and read about sales at the weekend. Gaining an expert understanding of something you’re not naturally drawn to is harder but not impossible. However, like all industries, sales still had a lot of unsolved problems which I could tap into. I really love solving problems. Luckily, it turns out that people really like talking about their problems. This comes in use when you’re a product company and your primary goal is to solve your customer's problems. Digging through the noise to find the signal in their sea of problems is a whole blog post in itself. However, I learnt a very important lesson here. Conversations with customers are the foundation of successful product teams, they’re the gold dust. Did the customers care that I didn’t know everything about the sales industry? No. Did they give me a hard time asking ‘stupid questions’? No. The truth is people just really like to share knowledge and be heard. And I was happy to receive it!
So if you’re not already speaking to your customers on a weekly basis, start doing it. It doesn’t have to be a long or even structured chat. Just sit down with some customers and talk about their problems. You never know what you’ll find.
Rule #5: Find the right tools
Without a shadow of a doubt, the right tools help. There are many replacement methods you could use in place of purpose-built product-focused tools, however, in my experience, it’s better to just take a leap of faith and utilise the great tools out there.
Instead of simply giving you a list of our product tech stack, I am going to outline the problems we faced and the tools we found as our solutions.
How am I supposed to collect and manage user feedback from all of our customers?!
We use ProductBoard to efficiently collect feedback from a variety of sources, such as Intercom, and translate it into a backlog of user needs. Note, we’re not generating a backlog, because fuck feature backlogs. Best to start with the need and work upwards.
I want to know how our customers are using a part of our platform but we haven’t added any product tracking!
We used Amplitude before to track how our users were using the product. The problem we found was that if you hadn’t manually defined an event, you were out of luck. We found Heap, a great startup working to solve this problem. Instead, they record all of your data all of the time. If you figure out you need something, just define the event and boom, it collates the data for you. This has been invaluable to us.
I want to talk to people who use a specific part of the product frequently. I’m sending emails but not getting anything back!
We found that sending blanket emails round to our users hoping that some would give us some feedback was like setting up a meat stand at a vegetarian bbq; it yielded zero interest. We recently moved to Intercom where we can now directly target users of particular parts of the platform with messaging to gather feedback and assess the impact of our releases.
I’m getting really clogged down by hours of customer video recordings, writing these up is almost becoming a full-time job!
This had become a really big problem for me. As the leader of product alongside being responsible for both design and dev I wear many hats and have almost zero time in between. I could not be wasting my time transcribing. Luckily, Otter.ai came to the rescue. Otter allows you to upload a video call and will automatically transcode the audio. It even helps with tagging who’s saying what.
It’s becoming quite a pain to go backwards and forwards with customers on arranging meeting times
We use Calendy to arrange meetings with customers. It lets you sync it to your calendar, set your availability and have customers book into slots of their choosing.
I hope you enjoyed my experiences of getting into product over the past year. It’s been a crazy year even without the pandemic playing its part. I am sure I have a lot more to learn and I cannot wait for the challenges to come. More problem-solving!
I’ll be documenting my experiences with growing a product company as we rapidly expand our team at OneUp. If there’s any part of my journey that you’d like me to write about, let me know in the comments.
