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: Free Your Product Roadmap and Ditch the Timeline - Mind the Product
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: Our Slack Community Has Reduced Churn Rate
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: Tech Debt Talk: 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: Release Notes - ProdPad Help
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!
I can definitely relate to having a product that requires a bit of work before you can show the value. To be fair, there are very few truly valuable products that don’t! That’s why onboarding is such an important aspect to just about any product, and why we’ve put so much effort into ours.
I’m happy to share some tips:
Make sure you understand what value your users are expecting. You can often see this based on what landing page or article they came in from, or simply by asking them in any number of ways. Only then can you begin to ensure that you’ll show them the value they are looking for.
Onboarding should align the goals of the business and the user. Find the things in your app that both impress the users by showing off value, as well as correlate with ‘success’ (success metrics to us include things like conversion to paid as well as ongoing renewal and referral). We discovered these success metrics through data, and a lot of our aha moments came from simply having lots and lots of conversations with our customers. We do tons of 1-on-1 demos of ProdPad, and you can often actually hear the gasps of delight when we get to certain areas. Those are the wow moments that we learned to prioritise!
Also, a good onboarding constantly evolves. What worked for you in early days will need to be adjusted as you learn more and as your market changes. Like anything, test, measure and iterate. Good luck with your upcoming launch!
That’s such a great distinction about the signals that any pricing change inevitably influences. What I meant was that ever so often teams chase “successful” experiments, ones that promise results over those that lead to lessons.
And you’re absolutely right, going back to the central goals of experimentation can be so helpful! Whether an experiment confirms a hypothesis or not, you’ve returned with something you didn’t know before.
Thanks for sharing your beautiful take on this, Janna!
We started on the other end of the spectrum. As four friends who had set out to build something challenging together; the ideas came much later. Yet, looking back at those early days, I’d say the “inability to measure what could have been” remains as true for us. Telling from the (bittersweet) clarity of hindsight, we, too, could have explored some things very differently.
And I’m saving this quote, the most thoughtful articulation of the matter I’ve come across:
“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!”
), 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.
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).
) 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!
