# I'm Janna Bastow, co-founder and CEO of ProdPad. AMA! **URL:** \ **Category:** AMAs\ **Tags:** past-guests, bootstrapping, pricing, product-roadmaps, user-onboarding\ **Created:** [April 20, 2020, 6:18pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347 "2020-04-20T18:18:01Z")\ **Posts on this page:** 14\ **Page:** 2
**Author:** ![Janna](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/janna/32/267_2.png) [@Janna](https://gorelay.co/u/Janna)\ **Post date:** [April 23, 2020, 11:53am UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/21 "2020-04-23T11:53:05Z")
> [@sachinanand](#): > > Hi Janna, > > Thanks for doing the AMA and great to see a bootstrapped success story. As a company based in the UK what were the key scaling tactics both in terms of marketing and outbound sales process that you followed to expand to North America? Hey Sachin, thanks for your question! 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. ---
**Author:** ![Janna](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/janna/32/267_2.png) [@Janna](https://gorelay.co/u/Janna)\ **Post date:** [April 23, 2020, 12:01pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/22 "2020-04-23T12:01:24Z")
> [@Logesh](#): > > Hi Janna, > > Thanks for doing this AMA, we have 3 areas where we would like to learn your experiences > > 1. In your experience, what is the tipping point that would trigger a change in product road-map? and the question of why now? > 2. Talking of tricky stakeholder (we assume internal), what are your experiences rather challenges in aligning that tricky stakeholder to your product road-map change > 3. With the dynamics of product road-map change in a bootstrapped organisation, what are your inputs to maintain runway in the lines of funds, team motivation and also fulfilling product development needs > > Looking forward! > @Deepika @Logesh > www.datsy.in 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](https://www.mindtheproduct.com/free-your-product-roadmap-and-ditch-the-timeline/) ---
**Author:** ![Janna](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/janna/32/267_2.png) [@Janna](https://gorelay.co/u/Janna)\ **Post date:** [April 23, 2020, 12:09pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/23 "2020-04-23T12:09:54Z")
> [@davidhart](#): > > Hi Janna > > Firstly, congratulations on building a boot-strapped SaaS company! > > With that in mind, on the journey to a startup’s first $1m in ARR, one of the big challenges is raising money. Once that is achieved, the focus can turn to other big questions around product market fit, go to market and team etc, before inevitably coming back round to funding again! > > My question is, what were the biggest challenges you faced as you started to gain traction and to what extent (if any) do you think the boot-strapping aspect has either slowed you down or taken up more of your time than you would have liked? With hindsight would you have done anything differently? > (sorry, that’s three questions!) > > Thanks > > David 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. For anyone who wants to know about our enterprise offering, check it out here: [Product Management Software for Enterprise](https://www.prodpad.com/enterprise/) ---
**Author:** ![wingman4sales](https://avatars.discourse-cdn.com/v4/letter/w/f0a364/32.png) [@wingman4sales](https://gorelay.co/u/wingman4sales)\ **Post date:** [April 23, 2020, 12:17pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/24 "2020-04-23T12:17:05Z")
Thanks Janna, very relevant advice and a valuable reason to force me to put it down in writing. ---
**Author:** ![Janna](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/janna/32/267_2.png) [@Janna](https://gorelay.co/u/Janna)\ **Post date:** [April 23, 2020, 12:24pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/25 "2020-04-23T12:24:39Z")
> [@ncameron](#): > > Hey Janna, > > 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? > > thanks! Hi Neil, nice to hear from you! 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](https://www.prodpad.com/blog/slack-customer-community/) ---
**Author:** ![Janna](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/janna/32/267_2.png) [@Janna](https://gorelay.co/u/Janna)\ **Post date:** [April 23, 2020, 12:31pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/26 "2020-04-23T12:31:48Z")
> [@Anushree](#): > > Hi Janna, > > Thanks for doing this AMA! 🙂 > > Given that you have been able to successfully bootstrap your startup, what advise would you give to an early stage startup with minimal revenue on how to sustain in these COVID times? > > Thanks, > Anushree 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. Good luck out there, and stay safe! ✌ ---
**Author:** ![Janna](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/janna/32/267_2.png) [@Janna](https://gorelay.co/u/Janna)\ **Post date:** [April 23, 2020, 1:15pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/27 "2020-04-23T13:15:12Z")
> [@raviramani](#): > > Hi Janna, > > 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 > > 1. Bugs that need to be fixed quickly > 2. Change requests from customers (in most cases unavoidable as we support custom workflows) > 3. 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? > > Thanks > Ravi 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](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: [Release Notes - ProdPad Help](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 💪 ---
**Author:** ![Janna](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/janna/32/267_2.png) [@Janna](https://gorelay.co/u/Janna)\ **Post date:** [April 23, 2020, 1:33pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/28 "2020-04-23T13:33:41Z")
> [@Vengat](#): > > hi Janna, > > Wonderful to see you here! Hope you and the Prodpad team are dealing with these turbulent times well. > > Having known Prodpad and followed your talks, very excited to use this AMA to learn more. > > Here are a few questions: > > 1. As the CEO/ founder with a “product bias”, do you continue to spend a disproportionate amount of time on the Product function or or do you spend time equally between all functions now). > 2. “Talking to customers” - is this some thing that you pro-actively continue to do. In its current stage of Prodpad - how many customer calls would you say you do per week or month. > 3. Tell us more about the product analytics tools/ practices that you follow to understand how are customers using the product. > > Vengat 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. I love talking to our customers! As a matter of fact, my calendar is open for roadmapping clinics ([Book Your Free Roadmap Clinic](https://www.prodpad.com/resources/roadmap-clinic/)) and demos ([Check out a ProdPad demo or book a deep dive with an expert](https://www.prodpad.com/demo/)) and whatever other conversations come my way. 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/](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. ---
**Author:** ![raviramani](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/raviramani/32/168_2.png) [@raviramani](https://gorelay.co/u/raviramani)\ **Post date:** [April 23, 2020, 2:09pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/29 "2020-04-23T14:09:23Z")
Hi Janna, 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. Best regards Ravi ---
**Author:** ![astha](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/astha/32/391_2.png) [@astha](https://gorelay.co/u/astha)\ **Post date:** [April 23, 2020, 3:22pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/30 "2020-04-23T15:22:27Z")
Hey @Janna, 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! ---
**Author:** ![astha](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/astha/32/391_2.png) [@astha](https://gorelay.co/u/astha)\ **Post date:** [April 23, 2020, 3:25pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/31 "2020-04-23T15:25:54Z")
Also, a big thanks to @wingman4sales, @jay, @pthaine, @sachinanand, @Logesh, @davidhart, @ncameron, @Anushree, @jonny, @raviramani, and @Vengat for joining in and sharing your questions and challenges with us so candidly. Hope to have you join us for the future AMAs as well! ⚡ ---
**Author:** ![Janna](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/janna/32/267_2.png) [@Janna](https://gorelay.co/u/Janna)\ **Post date:** [April 23, 2020, 3:50pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/32 "2020-04-23T15:50:37Z")
> [@jonny](#): > > Hi Janna, > > 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! Hey Jonny, great to meet you! 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! ---
**Author:** ![Krish](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/krish/32/72_2.png) [@Krish](https://gorelay.co/u/Krish)\ **Post date:** [April 24, 2020, 3:06pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/33 "2020-04-24T15:06:28Z")
> [@Janna](#): > > Thanks for your question Krish! > > 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. Thanks, Janna! 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 doing this session! 🙂 ---
**Author:** ![rajaraman](https://sea2.discourse-cdn.com/flex020/user_avatar/gorelay.co/rajaraman/32/399_2.png) [@rajaraman](https://gorelay.co/u/rajaraman)\ **Post date:** [April 27, 2020, 2:00pm UTC](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347/34 "2020-04-27T14:00:44Z")
> [@Janna](#): > > > [@rajaraman](#): > > > > Thanks for doing this, Janna! So glad to have you on Relay. 🙂 > > > > > ProdPad’s journey began with you and your co-founder scratching a particular itch. And that seems to be a passionate starting point for a lot of founders. With this vantage of having chased that initial, personal problem and having scaled it to its exceptionally well received, current shape, what are some of the questions you’d nudge your younger self to ponder before taking the plunge? > > > > > > Thanks, > > > Rajaraman > > Hi Rajaraman, I love this question! > > 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! 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!” Thanks, again, for taking the time! This has been a great session. -Rajaraman [Previous page](https://gorelay.co/t/im-janna-bastow-co-founder-and-ceo-of-prodpad-ama/347.md?page=1)