Thanks for taking time out for this AMA. I’ve been to a few Product Tanks and one Mind the Product conf, I would say that you and your team have one of the finest examples of a synergistic product + community.
We’re an early stage, bootstrapped b2b SaaS startup that help teams build, share and measure their progression frameworks and career pathways. Companies like Farfetch, Xero and Chargebee use us to help their team understand “what good looks like”" in every role at every position.
We currently run a tremendously popular resource https:// progression.fyi which generates many of our leads. We’re keen to turn this into a vibrant community and maybe even a conference at some point.
My question is this: what advice do you have for time-poor, cash-poor, early stage founders looking to build out a community alongside their product?
We’re also a bootstrapped business aimed at tech teams – but more focused on career pathing and skill development. Great to meet you!
We’re about to launch, and have been thinking hard about what to measure and how to measure it when looking at our first 30 days funnel. I really enjoyed your churn.fm interview around giving extra trial time, gamifying trials etc.
Our product (I suspect like yours) involves a certain amount of ‘work’ to get set up before you can start feeling the value. How would you recommend we encourage users to start creating content, spending meaningful time using our product based on the hope of future value?
Also any tips for how we might bring that demonstration of value before the point at which people need to pay? How did you give people really early ‘aha’ moments?
Thanks for doing this AMA. Our company operates in the document workflow space with specific focus on publishing. Our SaaS platform has about 40 customers right now and are working towards reaching the 1000 customer goal to truly hit PMF. One of the problems we have had so far is sticking to our product roadmap. Some of the reasons for this are
Bugs that need to be fixed quickly
Change requests from customers (in most cases unavoidable as we support custom workflows)
Our customer setups still require some configuration from the developers. This is something we are actively working to fix.
With just one development team of about 10 developers, we are currently struggling to keep our product progressing as fast as would like. Could you share some insights on how to tackle this problem?
Pricing experiments should be fundamentally structured just like any other experiments. Start with a hypothesis, outline what problem it’s expected to solve or impact it’s expected to have, and devise a way to test (as much as possible) discrete elements so you can observe whether changes made a difference or not. That said, the nature of pricing makes it unique to test, as a lot of companies worry about the optics of ‘playing’ with pricing in live environments and the potential impact on their brand, while not seeing anything wrong with running A/B tests that change other elements like the interface. Fortunately, not all experiments need to be run live! Pricing surveys, customer interviews, and other analysis jobs can get you a long way in understanding the impact of adjusting pricing.
The second part of your question might be a bit of a trick question, as better experimentation is a key part in enabling better decision making. Perhaps it’s worth qualifying what we mean by a good experiment. Any experiment should be started with a hypothesis and be given enough context that you and your team know what decisions are hanging off the experiment before you begin. There’s no point running experiments if it’s not clear what you’re expecting to see change or why.
It’s true that we build ProdPad to success by scratching our own itch. After all, we were both product managers at the time and needed tools to help us do our jobs better.
However, I think it’s remiss to assume that the best thing I could have done was to solve the problem closest to me. Had I taken a bigger step back, I could have explored a wider range of potential problems to solve, and likely found other opportunities that were just as, or even more lucrative than the path I went down. I think the common trait of ‘scratching your own itch’ as a successful starting point for entrepreneurs is muddied with survivorship bias and the inability to measure what could have been. I think that if more entrepreneurs spent more time in pure research and discovery mode, before picking a product/service to provide, we’d see a lot more value being created!
I think a roadmap is important at every stage. Now, keep in mind that I don’t think of a roadmap as a list of features to be built. In no way is it a commitment. Instead, think of it as a way to outline and check your assumptions about the obstacles your business will face, and how you might tackle them. In this way, your roadmap is more of a prototype for your strategy - not something that perfectly captures the final plan, but instead a device to help communicate where you are now, where you hope to get to, and what problems you will need to solve along the way.
If the rest of the team understands the problems on the horizon and there’s an agreed strategy on what order you’ll tackle them, it means everyone can pitch in to help take down each challenge as they come up. Having a roadmap hugely empowers your team, whether large or small.
Your question strikes at the heart of why having a feature-based roadmap isn’t a great idea (okay, there are many reasons, but this is just one!). When your roadmap is a list of features (or worse, features and deadlines, like on a timeline roadmap), it gives the impression that you’re promising a bunch of future improvements, and can cause some customers to hold off on purchasing until something comes to life. As you guessed, it can also affect your pricing experiments. This is why I always recommend to focus on selling what you have today, and using your roadmap as a place to identify the problems you might solve in the future. Your roadmap, then, becomes not a promise of things that will be delivered (which helps no one!), but instead a tool to help you check that you’re looking at the right problems. Test the assumptions on your roadmap just like you would test a prototype for a new feature. You’re not promising that it’ll look like the first prototype, but you’re simply using the prototype to check that you’re on the right track.
Back to your original point, don’t risk muddling up your messaging (and your experiments) by leaning on future features, so keep this level of detail off the roadmap.
While we were founded in the UK, we always knew that the market was going to be global, and that a large chunk of it would be based in the US. We made a decision very early on, before our first sales, to default to a US-centric self-serve platform: Prices have always been in USD, and our writing style guide follows American standards. Beyond making ourselves available to a global audience, we didn’t have specific tactics to tackle any one market - we don’t do outbound sales, but instead focus on giving our inbound leads the best experience.
Good questions Logesh! I’ll be able to answer the first two of them, as I didn’t quite understand the third one.
To your first question about triggering changes in your roadmap, it probably helps to keep in mind that lots of things will change your roadmap. Every day, as you build and measure, you should be constantly learning, and those lessons will be translated into new hypotheses, new experiments, and sometimes even entirely new problems to tackle on the roadmap. Don’t think of your roadmap as a fixed document outlining what will be done, but instead a flexible artefact that is used to outline your assumptions and change them as you learn more. It’s there to make sure that you and your team have the same assumptions, and that you’re all pointing in the right direction. If you learn something new that means you need to change your course, capture it in your roadmap and make sure everyone’s on board!
This takes me to your next question, about how to get tricky stakeholders on board with your roadmap. The best thing you can do is change your language around your roadmapping processes. Don’t talk about features and delivery dates on your roadmap - that’s your release plan which is a different, and much shorter term document. Instead, talk about the roadmap as a prototype to check your assumptions about the challenges the company will face going forward, and the experiments you might run in order to solve each of the problems. Take the pressure off the roadmap from being some perfect oracle of what will be build, and instead take advantage of what it’s strong at, which is checking assumptions about the future. That said, different stakeholders can be tricky for different reasons. If you find that your hands are tied and you’re still being asked to make an old school timeline roadmap, here are a number of ways you might break it down and make your argument: https://www.mindtheproduct.com/free-your-product-roadmap-and-ditch-the-timeline/
Ha, it boggles my mind this concept of raising money and then creating something that’s useful for the market, only to have to go back for more money round after round. It just never felt like the natural path forward for us. We made a decision early on at ProdPad that we weren’t going to go for funding, and that instead, we were going to focus on building something of value that people would pay for, and fund it that way.
That path was only an option because both me and my co-founder were builders and were able to make a working, sellable version of our product ourselves. We had a couple hundred customers and nearly $15K MRR before we looked at growing our team and getting help. It took time to build, but in hindsight, certainly not more time than we would have spent knocking on doors trying to get the multiple rounds of funding we likely would have needed (as everyone knows, you never just get one round!)
It was also harder to build trust in the market in early days. For some reason, large companies tend to be distrustful of bootstrapped businesses, even if they are profitable and self-sustaining. Because we kept our team small (we’re still fewer than 30 people! ), it meant that we’d sometimes be compared against competitors with 100s of team members, even if they only had that team because of a huge amount of debt. Thankfully, the balance swings over time, and we’re now the player in our market who’s most suited for large enterprises. After a certain number of years, enough ‘proof’ from other companies using the product (we’ve now got well over 1000 companies worldwide), and building our team and processes out to meet the needs of large companies, we found that the large deals were easier and easier to close each time.
One thing that’s important to point out is that ProdPad and Mind the Product are different companies with different teams and goals. I’m the co-founder of both, as I was simply an energetic product person who both wanted tools and wanted to meet other people who had the same struggles I did.
At one point in time, I tried to split my time between both ventures: building ProdPad, and growing Mind the Product. As you might expect, it was way too big of a job, and so I largely stepped back from an operational role at MTP about 5 years ago.
ProdPad’s growth is almost entirely down to inbound leads that we generate from writing and sharing our insights, and working with a wide range of communities. We often sponsor Mind the Product as well as lots of other product, design, UX, and customer success communities and events that happen. By working with other groups this way, it meant that the ProdPad team wasn’t bogged down by the immense amount of work involved with running events, moderating communities, or doing otherwise distracting activities. Instead, we can focus on building a great product and a great experience to go with it. My advice is to not try to build a vendor-specific community, but instead look at where the community happens to already be gathering, and support those groups. It’ll save you a lot of time and aggravation, and give you the freedom to reach a lot more people by being a supporter of a wider range of groups.
That’s not to say to not engage the community that naturally forms around your product. Here at ProdPad, we opened up a Slack group just for ProdPad customers, which is a great place for them to share tips on how they use the product, and generally be closer to our team for two-way conversations. It’s super low-fuss, and adds value to everyone who joins. We wrote about our Slack group here: https://www.prodpad.com/blog/slack-customer-community/
Hi Anushree, thank you for your question, and I hope you and those you care about are safe at this time. I admit that I’m not expert at running a business in Covid-19 times. Frankly, no one is! These are incredibly tough and bizarre times, and sometimes there are no easy answers.
Sustaining a business, through lean times, comes down to being able to be a cockroach. It sounds gross, but cockroaches are able to live on very little and are hardy as anything. In business terms, this means operating with minimum excess overhead, and without running a month-on-month cash deficit. During this coronavirus crisis, it’s the businesses that are able to hunker down and not run out of runway that will see it through to the other side.
If you’re not making money now, move your focus on to ways you can charge for your product or services, even if it’s different than what you would have done pre-Covid-19. After all, there are a lot of new problems to go solve for the world now, so perhaps there’s value to be added and money to be made there. If you are making money now, look to keep your costs below your revenues. We don’t know how long this will last, and every month you can buy yourself gives your team that much more of a chance to survive and come out the other side.
Hi Ravi, congrats on getting your first 40 customers! It’s an achievement to get there
I think the core problem that you’re having, with sticking to your roadmap, is that you’ve got a release plan, not a roadmap. It’s very common for teams to conflate the two, but it runs into problems like you’re outlining.
Things like bugs and customer requests shouldn’t live on your roadmap. If they are, then it’s more likely that you’ve got a list of ‘things to do’ vs ‘time’, which is essentially a release plan. Now, there’s nothing wrong with having a release plan, as it’s an important document! But the problem comes when you start planning things further and further out, making up potential release dates as you go. What you’re actually doing is overcommitting your team to building a bunch of things, without providing the flexibility to measure and learn between iterations. Your release plan should only look at what you plan on releasing in the short term, as in work that’s already been prioritised and is in progress.
You won’t find Product-Market Fit by just following all of your customer’s change requests and fixing all of their bugs. To get to PMF, you’ll need to take a big step back from the delivery mindset, and spend time discovering: What sort of problems do your customers really have and are willing to pay for? What sort of obstacles will you run into if you tried to solve those problems? Use your roadmap to outline your assumptions about these problems. The roadmap, as you validate it (as in, iterate and check it with more and more stakeholders to make sure your assumptions make sense!) will help shape your release plan.
You’ll never finish all those bugs or complete all those change requests. As your product matures and your customer base grows, you’ll find yourself having to say no to more and more, simply because there’s never enough time! Imagine the requests you’ll get when you have 1000 customers Instead, your roadmap will help make sure that you’re saying yes and no to the right things, therefore wasting less of your precious time. This is why we call it a Lean Roadmap (lean means to reduce waste).
Now, to your point about your team not progressing as fast as you’d like… remember that this is subjective, and frankly, you’ll never move as fast as you really want. Building great products does take time. That said, there are things you can do to speed things up:
Give the team clear direction and autonomy. They should understand the vision, and the problems on the roadmap, and how the business is being measured, and should be empowered to do their part in pushing the company forward. Sometimes the biggest bottleneck in a company is a founder who gets too in the weeds and has to give directions at every step.
Ditch arbitrary deadlines. Sometimes it feels like giving something a deadline will help hustle the work along to completion, but it actually has a detrimental effect. First of all, anyone working to a deadline is going to know to add some buffer to their estimates, or else run the risk of not giving themselves enough time. This then leads to the issue that work expands to fill the time allotted. You rarely see projects come in under, but you often see projects pick up scope creep and go over. If work is rushed through to a deadline, you can be sure one of two things is happening: either the scope is reduced and you end up with less of what you were hoping for, or more often, the quality is reduced. Oftentimes, you won’t even see this reduction in quality. It’s just a little bit of extra tech debt, but that stuff adds up. Over time, it’ll slow down your team from being able to deliver as fast as they could when the codecase was new and less buggy. Ditching timelines takes an element of trust in your developers, and you’ll need to work with them to have a shared understanding of what ‘done’ is, and how much time is reasonable to spend on any problem, so you don’t end up lost down rabbit holes. But you’ll end up with better quality and faster deliveries as a result of ditching deadlines. I spoke and wrote about this in more detail here: https://www.prodpad.com/blog/decisions-debt-and-other-dilemmas/
Make releases less scary. If your releases take a multi-day song and dance and only happen every few weeks (or god forbid, every few months!) then each release is fraught with stress. It creates a deadline for everyone, as if this release is missed, then the work won’t see the light of day for another long time. It creates stress, as if something isn’t perfect and needs to be iterated, there’s no easy way to do that. This means that the team spends more time planning and checking their releases, rather than just batting it out the door. A lot of companies think of continuous deployment as a tech exercise, but in reality it has huge value for the bottom line of the business. A team that can deliver with ease can switch between iterating and delivering and discovering, without the stressful build up of a big-bang launch. Our team here at ProdPad launches twice a week, like clockwork. For a team without deadlines, we sure get a lot done: https://help.prodpad.com/hc/en-us/sections/200110308-Release-Notes
I hope this helps! Best of luck with the next stages of your journey Ravi
As a company led by two product people, we’ve definitely had a bias towards product management as a team. We’ve even hired product people to take on roles in customer facing and sales roles here! Fortunately, good product management practices can help just about any area of the business - after all, what process can’t be measured, iterated, and learned from? Personally, I split my role now, and find myself in all areas of the business, but I’ll always have a special place for product activities. I have to make sure that I don’t swoop in and overly influence the team, as frankly, they are more capable than I ever was as a product manager.
Our team takes dozens of calls every month. Personally, I usually end up with 3-4 a week nowadays. It’s fewer than it was a few months ago as we’ve just hired our first person in the US (everyone, go meet and connect with Wes Galliher! https://www.linkedin.com/in/wesgalliher/ ) and so he’s now doing the demos in the US timezones. Up until late last year, I was doing a lot of demos in my evening here in the UK, to keep up with demand from our US market!
I’m glad you ask about product analytics. As for tools, we’re pretty tool agnostic. We’ve used a bunch, and have a whole stack that would take some time to describe, but we started simple, with some home-brewed analytics, and have gone from there. One of the best things we did as a business was hire a dedicated Data Analyst on to our team, back when we were still about 12 or so people in the team. If you don’t understand how people are using your website or your app, you can’t serve them well, so invest in these areas as soon as you can.
Thank you so much for your brilliant insights. You have analyzed our problems perfectly and suggested some great solutions. I really appreciate your detailed response and look forward to connecting with you again after we make some changes internally. I wish you the very best for your business.
Thank you so much for taking the time out to answer all the questions with such generosity and openness. There are SO many solid takeaways in there!
Your point on survivorship bias hits hard and how you personified the product roadmap — as more than just a timeline and feature set, but a prototype for strategy and a place to bucket your problems — is going to stay with many of us for a long time.
And I, for one, am completely amazed as I begin to visualize how the principles of product management fit into almost all areas of business… like you explained.
Thank you, again, for sharing your hard-won lessons and insights.
Hope to have you join us for another session very soon!