Product Stories: Recent Episodes
Trustshoring
Video In today’s video, Victor Purolnik, the founder of Trustshoring, talks about the things you need to pay attention to, clarify, and align when hiring remotely in order to succeed with remote hiring, hire the right people and of course have a smooth onboarding process. This will also allow your new hires to understand how […]
Video In today’s video, Victor Purolnik, the founder of Trustshoring, answers one of the most common questions about how to prepare for an acquisition and what buyers and investors look for in terms of tech due diligence. How can you prepare your business so that you get the best possible valuation, don’t leave money on […]
In this episode, Miguel Augustin, the COO and Fractional CPO, answerers one of the most common questions we receive from our clients which is - If we have a small development team, do we still need a product roadmap? The short answer to this is yes. Every time, regardless of the size needs a product roadmap. It will just be tailored to meet the capacity of the team
Video In today’s video, episode 3 of a four-part series, we sat down with Omeed Tabiei to discuss hiring and working with remote software developers and everything you need to know about contracts and jurisdiction. Omeed is the Managing Partner at Optimist Legal, a law firm focusing solely on SaaS businesses. The firm helps founders […]
Video In today’s video, which is episode 2 of a 4 part series, we sat down with Omeed Tabiei to talk about equity distribution and everything you as a founder need to know about setting up your business in a way that allows you to distribute equity to your employees easily and appropriately. Omeed is […]
Video In today’s video, we sat down with Omeed Tabiei, the Managing Partner at Optimist Legal, a law firm specializing on SaaS, helping founders set up their business, handle all things legal even up to the point of exiting and selling your business. In this first episode, which is part of a 4 part series, […]
Video In today’s video, part of a multi-part series, Miguel Augustin, the COO at Trustshoring, talks about Fractional advisors and what these seasoned professionals bring. In this first episode, we’ll talk about the Fractional CTO. We’ll define who they are, the roles and responsibilities of a Fractional Chief Technology Officer, and how you can maximize […]
Video In today’s video, part of a multi-part series, Miguel Augustin, the COO at Trustshoring, talks about product management, what it entails today, and how you can start to coach your product manager to become successful. If you’ve recently hired a new product manager or promoted one, this episode will show you how to get […]
Video In this video, which is the final episode of a multi-part series, Saravana Kumar, the founder and CEO of Kovai talks about how the $20m ARR SaaS uses artificial intelligence within their products to scale, as well as the key metrics businesses should be tracking and how founders can continue to upskill and grow […]
Video In this video, Victor Purolnik, founder of Trustshoring talks about the steps you need to take in the rare case that a software house or software agency decides to hold you hostage. This can happen due to a dispute over payments where the software agency or software house can lock you out of your […]
Video In today’s video, Victor Purolnik the founder of Trustshoring, talks about a common problem that most remote teams face which is how to effectively communicate as a remote team and have effective stand-up meetings. Victor has been helping saas businesses to build, launch, and scale with the help of remote development teams for over […]
Video In today’s video, Victor Purolnik, founder of Trustshoring talks about a common question he often gets from SaaS founders and that is where should you hire developers abroad, especially in Eastern Europe. Victor was in Warsaw, the capital of Poland and he talks about Warsaw and the opportunities and options you have as a […]
Video In the second episode of this multi-part series, Miguel Augustin, the Fractional CPO and Consultant Lead here at Trustshoring answers the question – Who’s job is it to build or develop the product roadmap? You can find part 1 here! – https://www.trustshoring.com/podcast/what-is-a-product-roadmap/ Here are other videos you might like! Effective techniques to prioritize your […]
In today's episode, we talk about the 7 most common software development mistakes we've seen from the last 10 years and how to avoid them.
Video In this video, Miguel Augustin, the Fractional CPO, and Consulting and Process lead at Trustshoring breaks down exactly what a product roadmap is and the signs of a failing or ineffective product roadmap Here are other episodes you might like Effective techniques to prioritize your product roadmap Solving common dev problems by doing SCRUM […]
Video In part 3 of our multi-part series, Saravana Kumar, the founder and CEO of Kovai talks about how the company maintains innovation, especially in today’s AI era, giving you some insights on how to position your SaaS for growth today. He also talks about how a multi-product saas company sells its products to different […]
In this video, Saravana Kumar, the CEO and Founder of Kovai.co, takes us through the importance of customer feedback in building and scaling a multi-product SaaS, the feedback loop that guides their roadmap as well as the productivity metrics and how they measure team performance at Kovai to drive saas growth! We also talk about […]
Video Summary Is it better to bootstrap your startup or seek funding? Let’s hear from Saravana Kumar, who was able to scale his bootstrapped business to $10 million ARR. This is the first part of a series of videos from our conversation with Saravna Kumar, the CEO and Founder of Kovai.co a multi-product SaaS Company. […]
In this video, Victor Purolnik, founder of Trustshoring breaks down what the software developer recruiting process looks like, what companies do differently, and how you can start recruiting in-house using these processes and tips. Victor also talks about the use of AI in the recruiting process, how to use it as well as how developers […]
In today’s video, Victor Purolnik, founder of Trustshoring, talks about the factors that make a job attractive to a software engineer, giving you insight into how to attract top engineering and product talent without competing on salary.
Today, we’ll be sharing a trick and showing you how to optimize your SaaS team with fractional leadership and avoid or rather save on the outrage fees that you’d normally pay to hire a CTO or CPO full-time which, especially in the United States can range anywhere between $200,000 – $500,000 a year with no […]
Are you making it difficult for your developers to work and collaborate with you? Most of the time when clients come to us, they are normally looking to improve the productivity of their development teams. Sometimes what’s missing is the right mix of seniority within their teams, other times, they just need the missing tech […]
In today’s video, we’ll take a look at the two pillars of SaaS security, and how to go about implementing them to secure your business. Failure to do so could mean the end of your business. You’d be surprised how SaaS companies may fail even to consider password updates once they stop cooperating with developers. […]
Has your MVP started to show some cracks? Have you started to have issues like poor estimates, communication breakdowns, and a chaotic development process? Today, we’ll be talking about how to move your MVP to the next stage of growth. At the beginning, an MVP is very capable of handling even a couple hundred users, […]
In today’s video, we look in-depth at what makes software development expensive and unpredictable. Have you ever found yourself marveling at the price disparity between software projects, wondering why some bear the price tag of a hypercar while others resemble the cost of a used Volkswagen? Well, here’s why!
We’ve been privileged to work with some amazing software engineers and dev teams and today we’d like to share the 6 characteristics that make up the very best high-performing dev teams. What are they? – Small size team – High seniority makeup – Similar language and culture – Dedicated full-timers- Versatility of Full Stack Developers […]
At its core, HIPAA revolves around two main rules – The Privacy Rule and The Security Rule. We already looked at what HIPAA is and the penalties involved. In this second episode, David we’ll break down everything about the two fundamental rules of HIPAA that you need to know! The HIPAA Privacy Rule provides federal […]
Today, we’ll be learning all about HIPAA compliance and the consequences of breaching the regulations, with our very own David Lee! David is a Fractional CPO here at Trustshoring! He has more than 5 years in the Health and IT space and was the CPO at Point Health which was acquired by its sister company. […]
How can you efficiently and effectively migrate your traditional desktop software to a modern app or a saas? Software as a service (SaaS) offers a compelling opportunity to businesses or individuals looking to migrate or port their old software to a modern application. This transformative shift modernizes applications and introduces numerous benefits, from simplified updates […]
How can you align your tech and product team to one goal? Have you been sensing a lack of clarity in your product development process? Today, we’ll be sharing one of the simplest ways to align your tech and product teams to a single goal – The 1-page product roadmap Learn how you can use […]
In today’s video, we talk about how to collect customer feedback in order to give you the best possible insights into how your customers are interacting with your product. We talk about the two bases of user feedback collection – Qualitative and quantitative methods, and how you can leverage them to help steer your product […]
What are API integrations and how can they help you expand and enhance your product offerings? Today, Application Programming Interfaces (APIs) serve as the backbone of software interaction and integration, enabling businesses to expand their services and enhance customer experience. For founders of software businesses looking to expand and enhance their offerings, understanding the intricacies […]
Crawling websites is the process of gathering data from unstructured web sources that are not primarily made to be read by machines. Basically what Google does when it’s trying to index sites but at a much smaller scale. The crawling robot uses a browser framework to act like a user and reads data This process […]
Preparing to switch your development team? In today’s video, I break down the 4 crucial things you need to know to have a smooth transition if and when you decide to change your development team. Switching development teams can be quite tedious especially when you are not prepared or you are in the middle of […]
Are you concerned about your SaaS idea getting stolen by software developers? Bottom line? It’s not easy for a software developer, or engineering team to steal your code and launch your SaaS Idea as their own. In today’s video, I explain why that is, and also talk about the very rare occasion where a software […]
Who is a fractional CPO and why are they one of the best-kept secrets in SaaS success today? I believe that this is one of the most underestimated roles in tech or SaaS companies. 💡 The Fractional CPO allows you to make the important tech decisions on what to build, how to build it, and […]
While Bitcoin continues to dominate headlines in the world of blockchain, a bigger question continues to loom – Why are there not so many blockchain startups yet? We’ve seen a lot of technology gain a wide range of adoption all over the world today like AI, with a lot of AI-based startups and apps, which […]
Have you heard about all the new AI-powered SaaS solutions popping up? Maybe you’ve been wondering how they work and how you can take advantage of this new AI age to power your business Learn why launching fast, efficient, and simple AI products can be a game-changer, giving you a significant edge over the competition. […]
Remote hiring has opened up huge opportunities for companies to access a wider pool of talent at an affordable cost. However, this has also come with its risks, and we’ve seen some of those in the software development space. In today’s video, I share some of my experiences hiring remote developers, to give you a […]
A lot of development teams and software houses have forgotten what it actually means to develop in an agile way. In this video, I use Google’s Gmail as an example of how to move from sprint to sprint, and how to prioritize and ship features! Discover how to properly leverage Agile for efficient, goal-oriented progress […]
Every software system requires maintenance and evolution throughout its lifecycle. So what are the strategies for software maintenance especially if you’ve got a small startup? In some cases, startups find themselves with products that don’t really need much development after a while or rather don’t need to add any new features. However, just like traditional […]
When should I switch from an agency to an in-house tech team? Should I even consider it, and if so when? This is another very common question that I normally get. The main thing to understand is that an agency is a single point of responsibility but also a single point of failure when it […]
Getting users to quickly start on your app by importing their data, can massively increase your retention! User onboarding is one of those things that every software company and business knows is critical but struggles to get right. I’d like to share with you a quick hack on how to quickly and cheaply get users […]
Should you get a technical co founder, hire a CTO or go at it alone? Every time I get asked this question, I normally like to advise founders to think about the stages that every startup moves through and the type of tech lead they need for each stage.
I got asked a very interesting question about programming languages and which one I would choose if I was to start all over again. The short answer is JavaScript. Why? Lets talk about it
When it comes to project estimations today, the huge debate in the software industry normally revolves around estimation techniques and which technique is better. While the estimation techniques matter, the biggest problem today is forgetting that these estimations need to be analyzed deeper. In this episode I talk about how to open up that much needed dialogue, to help you get better estimations from your developers.
Every founder of a saas business wants to know that the development work being done either by their in house team or an outsourced agency is of the highest quality. In this video I discuss how founders can judge the quality of their code base, as well as the 3 traits of excellent code!
One of the most common questions in the software development today is what it costs to build a certain app or a software that does x. In this short video, I discuss the true cost of software and what you should be thinking about when you start to build.
There’s more than one way to get into the SaaS field. Whether you already have a SaaS or are just considering it, you may be interested in becoming an investor, running multiple SaaS products instead of building one from scratch. How can you do that? How do you decide what to buy and when to sell?
Pricing is an important issue for any SaaS company, and it’s not always easy to understand how to best use pricing to your company’s advantage. Today you’ll hear from Dor Sassoon, the co-founder of Stigg. Stigg is a platform that enables developers to ship pricing plans faster and introduces end-to-end self-service solutions for SaaS.
Summary: Are you looking for a way to understand GDPR, HIPAA, SOC2, DPA, and others so that you can sell to enterprise customers? Today’s guest is Girish Redekar from Sprinto. He knows all about compliance with these certificates because he’s gone through the process dozens of times, and his company works with these compliances. In […]
Summary: Should you hire a CTO or get a technical co-founder? How can you hire a great engineer? Why are estimations such a mess? Today’s guest is Aman Agarwal, author of Tech Fluent CEO. Aman is exceptional at explaining tech to non-technical people. Aman shares the most common questions he gets from non-technical founders. Episode […]
Summary: Go big or stay small? Implement the best from both worlds. Today’s guest is Blake Folgado, CEO and Co-Founder of Outside. Blake has seen it all and shares his insights on how to innovate fast by staying small until the ability to achieve product market (PM)-fit. Episode Highlights/Topics: Parental Influence: How Blake started his […]
Summary: Are you struggling to collect, enter, print, and validate user feedback to ship new features that people actually want and will use? Today’s guest is Toms Blodnieks, COO and Head of Product and Business Development at DeskTime, a time-tracking SaaS for teams. Toms shares how DeskTime’s framework inspires and turns user feedback into useful […]
Summary: There is one investor that will always lend you money, but it comes at a very high price. Technical debt—what is it, how do you borrow against it, how big is the interest, and how do you pay it back? Today’s guest is Alex Omeyer, founder of Stepsize. Technical debt comes in different shapes […]
Summary: What does working at Amazon teach you for your life as an entrepreneur? Why get a CTO co-founder, even though you are technical yourself? How can you build a remote team? Today’s guest is Marin Smiljanic, CEO of Omnisearch, who tells his story of going from being an Amazon engineer to a remote startup […]
Summary: Everybody knows and hates bugs in software. You can’t fully avoid them, yet every single one is one too many. What can you do to have fewer bugs in your software? Today’s guest is Maximiliano Contieri, engineering project manager at Avature and computer science teacher at the University of Buenos Aires. He talks about […]
Summary: Why is my app so buggy, and what can I do about it? Why can’t developers just test their own code? Who’s fault is it and who is to blame? Today’s guest is David Burns, Head of Open Source at BrowserStack, a popular platform for testing apps and websites in different browsers. David takes […]
Summary: Is your app slow or releases a pain that produces bugs or downtime? Are AWS, Docker, Kubernetes, and CI/CD just techie talk? What are DevOps and current server setups that ensure smooth releases and scalability of applications? Today’s guest is Alex Becker, founder of Prioneer.io, a SaaS tool that prioritizes customer requests. Alex is […]
Summary Attracting enterprise clients often involves an entirely different approach than for smaller clients. What does it take to lure the big fish? Today’s guest is Alexander Baron, co-founder of Top.Legal, a SaaS tool that helps with smart collaboration on contract frameworks and negotiating agreements with clients. Episode Highlights/Topics: Automation: How and why Alexander got […]
Summary Have you lost control over your development sprints? Is SCRUM just wild theory for you, and you’re not sure if you’re doing it right? Today’s guest is Sohrab Salimi, founder of SCRUM Academy and a certified SCRUM coach. He will guide and give us helpful advice.through the most common mistakes startup teams make when […]
Summary Have you lost control over your development sprints? Is SCRUM just wild theory for you, and you’re not sure if you’re doing it right?
Today’s guest is Sohrab Salimi, founder of SCRUM Academy and a certified SCRUM coach. He will guide and give us helpful advice.through the most common mistakes startup teams make when building software.
Episode Highlights/Topics: * How and why Sohrab transitioned from medical school scrubs to SCRUM Academy * Right is Relative: SCRUM is not always the right approach, depends on concept/project * Empirical Process Control: If aware of hypothesis, define/design experiments to improve * Discovery/Delivery: Do you know what customers want? Get validation on assumptions * SCRUM: Intention is to continuously improve by collaborating and delivering value * Framework: Why development teams do it differently—it is intentionally lightweight * Sprint Lengths – Two Choices: + What is the minimum amount of time needed to be spent to get a real product + How much time can be invested before getting customer feedback * Review: Watch and learn from your customers by involving and engaging them * Retrospective: + Provide safe space to talk about problems and challenges + Prioritize problems and challenges to identify root causes + Create and execute solutions to problems/challenges that will be done * SCRUM Master: What are their responsibilities? Continuous improvement * Estimations: Hours or points are used to fulfill need for predictability of tasks, capabilities * SCRUM Remote-First Environment: Any tool that fosters collaboration and transparency
Resources/Links:
Trustshoring
Sohrab Salimi on LinkedIn
SCRUM Academy
Agile Fundamentals
The Lean Startup
Alexander Osterwalder
Shape Up
Project Management Body of Knowledge (PMBOK)
Slack
Tuple
Jira Issue Tracking Tool
Pivotal Tracker
Read the transcript:
Victor [00:21]: Welcome back to the product stories podcast, hosted by Victor Purolnik. This podcast helps founders like yourself to find leaner ways to build successful SaaS products. Sohrab welcome to the show.
Sohrab [00:35]: Thank you Victor for inviting me.
Victor [00:37]: Yeah. My pleasure. How did you get into scrum being a scrum professional?
Sohrab [00:43]: That’s going to be a long story, but I’ll try to cut it short. So initially I studied medicine. I’m the only medical doctor in this field that has achieved the highest credentials in the world of agility. And I actually finished medicine and I didn’t really know which specialization to do. I liked the intellectual challenges of being an internal medicine doctor, but that was just too slow. If you have a patient, you just give them a bit of drugs and then you have to wait until things come. And I like the action in surgery and there’s really no mix between these things.
[01:23] So I was in the middle of a debate internally in my head. And one of the ideas that I had was also to look into other fields. As my parents were both entrepreneurs I had this entrepreneurial neck in me and I was like, okay, let’s explore this. And let’s look at the world of business and let’s look at what kind of opportunities are out there. And ultimately I joined Bain & Company one of the three big strategy consulting firms. And I stayed at Bain for almost three years, then my wife said, as long as you’re working there, we’re not going to have any kids because you’re never at home. So I left Bain.
[01:57] I founded a company with a friend from school and I also consulted my parents’ IT consulting company on what could be like the next steps that they do. And as a startup founder, I obviously in 2010, 2011, read the book, Lean Startup. And for me it was always like, why wouldn’t you work this way? Because if you think about it, basically every scientist, every medical doctor is clear that anything that we have in our head is a hypothesis. And what do we have to do with hypothesis, is to validate them? We have to run experiments in order to understand to what extent this hypothesis is correct and to what extent it is not correct?
[02:38] So The Lead Startups really resonated with me. And at the same time, I was like, oh, this is very different to what most of the clients that I worked with during my time at Bain do. And it was also very different to what my parents IT consulting company was doing and consulting their clients on. So I looked into this whole space and identified that connected to the lean startup, there’s this upcoming topic of agile software development, particularly scrum. And together with my dad, we looked at this and said, maybe that’s like the next thing that the company should focus on. And as part of that, of course, we had to like train ourselves.
[03:16 ]We had to train our employees, our colleagues and then also look for clients that were looking into this particular thing. And as part of that this whole topic of agility, particularly scrum is one framework to get there. It resonated really well with me. And I just made it my decision to spend the rest of my career probably learning about this stuff, teaching people around this topic. And as part of this journey ultimately became a certified scrum trainer, agile leadership educator, and all of that.
[03:47] And today I spent around 50% of my time teaching classes, running trainings, building online courses, and the other 50% I spent with companies, small ones, but also pretty big ones on implementing these things in reality. And then learning from that. And in the past years, I’ve had a lot of work in the software space, but more importantly, maybe, or more interesting for me, I did a lot of work in the non-software space. So building a truck or medical devices participating in this COVID tests, et cetera. So it has been quite a journey and I’m still excited about the topic.
Victor [04:26]: Well, indeed is quite a journey. So you started right with the roots of agile and scrum as well. I remember those days when nobody heard of it. It’s like this big new thing. And so when you consult clients, or you see different projects, different companies, different maybe even goals or circumstances, is scrum always the right approach?
Sohrab [04:50 ]: Not necessarily, I mean, right is always relative. So for me, I mean, the topic that I try to drive is the overall concept of being adaptive to the situations that you’re in. And I think based on that, claiming that one framework be it scrum, be it something else, is always the right approach would be contradicting the overall philosophy that I try to teach people. And even within a framework like scrum, what I really like about is that there is this continuous improvement of the process as well. And as part of that, the framework.
[05:28] So to your question, no, it’s not always the right approach, but I think what is one of the most important things and what could be considered as on a meta-level, as a right approach is the concept of empirical process control, where you are aware that you have hypothesis in your mind, as I mentioned earlier. And where you start defining experiments or designing experiments that can help you uncover what the reality is and get better and better over time.
Victor [05:57]: That makes perfect sense. And so do you see that more and more people are taking this validation part outside of code and actual coding, rapid prototyping or things like that?
Sohrab [06:11]: To some extent, not enough unfortunately. There is this whole movement coming up about discovery. Because a lot of people associate agile ways of working primarily with delivery. The moment you know what you need, now you start to build it. Build it in small increments and in sprints, and then you get it out of the door faster. I never thought that this would be the intention of agile or scrum as one of the frameworks in that space. For me, the discovery piece. And as you mentioned on rapid prototyping helps you do that.
[06:45] Like defines smaller experiments to validate your hypothesis, everything that Alex O Valer and his company strategize and do around business model design and innovation. All of that for me is also part of the same philosophy, part of the same thinking, where with as low cost as possible, you try to get validation on certain assumptions that you have. But not enough organizations, especially not enough big organizations, startups do this quite well nowadays, because there’s so much literature out there in the startup community people really challenge each other as far as I can see, but not enough of the big organizations are aware of this whole discovery piece. They still believe that they know what their customers want. That’s the assumptions that they still hold. And based on that, they’re primarily looking at delivery options, not so much at discovery options.
Victor [07:40]: And so when we speak about discovery, then obviously the one hour session where you go over requirements, that’s not the kind of discovery that you mean.
Sohrab [07:50]: No, no. I mean, if you do that with clients, it could be, but still probably not enough, but just within your team, going over requirement and creating clarity around that requirement and align it. It’s an important process, but that’s not what we mean with discovery. With discovery we really mean being aware of the assumptions that you hold and the hypothesis that you have, and then designing experiments with code or without code. Usually without code, it’s cheaper to validate to what extent those assumptions are correct or not. And then inspect an adapt based on that.
Victor [08:25]: How would you then compare something like Shape Up to this model? Would you say it’s actually aligned in that philosophy? It seems like it from what you’re saying.
Sohrab [08:36]: Yeah. Shape up. You mean the one from Base camp? Victor [08:39]: Yeah.
Sohrab [08:41]: So I haven’t looked into Shape up in detail, so this as a disclaimer upfront, but I’ve read a bit about it. And based on what I’ve heard, both of Jason Fried and David [08:55 name] say and others, and based on the work that they do with their products. I think they follow a lot of these things or they do a lot of these things in a really good way. To my understanding, again, not too much into it is they do spend a fair amount of time on discovering the actual problem is, the needs, how that can be solved from both design and technology perspective. And then they implement it. And I think they give themselves like six weeks sprints. They don’t call it sprints, but it’s more or less the same concept.
[09:30] And within these six weeks where you try to solve a certain problem, you have a lot of autonomy on how to solve that problem. All of that resonates very, very well with my philosophy. And I think there’s a lot of overlap if you go beyond what a lot of the organizations have done with framework like scrum making it a mechanistic way of working. But if you really look at the essentials at the foundations of it, there’s a lot of overlap with what Shape up does again, I don’t know enough about it.
Victor [09:59]: Yeah, exactly. Thank you. Because that’s exactly what it seems like, that a lot of people when they think or hear scrum, they really only start from the moment you break down things into a billion tasks, try to sort them on a backlog and then throw them at the next sprint and just mechanically work on them, which almost sounds like waterfall to me at this moment. Not quite because you then get the flexibility, but just from a planning perspective and here’s my backlog and these are all the tasks that I need to do. Thank you. Planned upfront a lot of them are, is what I see.
[10:36] Versus show shape up where you have this shaping up phase of like, we’re putting back focus on this discovery thing. So this is very interesting. But now back to scrum, maybe. Why does everyone do scrum slightly differently? That’s what I see from a lot of development teams. They miss out a few of the ceremonies, or are they implement slightly different sprint lengths. Is that how it’s supposed to be?
Sohrab [11:04]: So scrum based on how I see it. And again, I don’t have the expectation that I have the one and only truth, but the way I see it, the way I also teach it, it’s intentionally a lightweight framework. So a lot of the criticism that I heard in the early days, especially from people coming from traditional project management, they were like, we need something similar to the project management body of knowledge PM book, which is like this thick. And I’m like, no, I think in the case of scrum, it is intentionally lightweight.
[11:38] Now the moment something is intentionally lightweight, it basically gives you a few constraints. But within those constraints, you have a lot of flexibility, a lot of autonomy. It basically gives you a canvas, but the type of picture you draw on it ultimately depends on you. And I think for me personally, I think this is a good thing. Now, with regards to sprint length, it is intentional that teams can choose their sprint lengths. And now one of the question that comes up is, so based on what should they choose, what their sprint length should be.
[12:10] And I always give them the two things. One is what is the minimum amount of time that you can spend, or that you need to spend in order to get a real product increment out? So something based on which you can gather feedback and learn that’s one. The other thing is how much time can you invest before you actually get customer feedback? If you can go six months without getting customer feedback, I don’t think anybody can really do that because worst case you might have spent this six month working on stuff that nobody wants.
[12:46] And finding the balance between these two things is really important for a team and whenever possible I try to go into one week sprint. It makes it easy. Monday to Friday. You don’t worry about anything over the weekend. Next Monday, you start with the next sprint. Most teams that I see work in two week sprints. And then there are a lot of frameworks around this if you think about like multiple teams working on the same product, like [13:09 inaudible] agile framework, et cetera. And let’s not go into the debate, which of these are good and which ones are not.
[13:16] But they basically tell every team they need to have a two week sprint, because then you have several of those two week sprints. You end up having a program increment, which is then ultimately three months. So the flexibility here I think is needed. The other reason is I think a lot of teams or people don’t understand the reason behind the individual events, or I think some people refer to them as ceremonies. Why do these things exist? Planning still clear.
[13:46] Everyone probably runs a planning. Daily that’s easy to do. Let’s do this one. The two things that are complicated and that a lot of teams don’t do are review and retrospective. And from my perspective, from my experience, both of those are actually the ones where you get the value of a framework like scrum. One is related to inspection and adaption on your product. So what are we building? And the most important thing about a review is that it’s not the team giving feedback to itself. It’s our stakeholders, ideally customers giving feedback to whatever we have delivered because that’s when we learn.
[14:29] And the intention of scrum, the intention of the review is to facilitate that learning process. And retrospective is about learning about how we collaborate. And if we don’t do that one, we probably won’t improve over time. And both of these things, especially the retrospective was also known as the Kaizen in the lean philosophy. Now think about how many organizations implemented lean, but they never implemented a true pattern or a true habit of running regular kaizens.
[15:04] But only then if you do this, you get the real benefits of lean and only then you get the real benefits of scrum. So I think in most cases, it’s not knowing why these events exist and why we should do them. And therefore they just skip them. And then it looks very different from team to team.
Victor [15:22]: That’s actually very interesting. And so what does a review usually look like? I have my customer sounding board that I invite, I demo them what we developed then we ask for feedback, is that ideally how it should look like?
Sohrab [15:35]: That’s one way to do it. You have your customers, you demo something to them, and then they give you feedback. Another way is you just tell your customers what you have developed, and then you let them demo it to you. Because in that scenario, you also see like, okay, how do they interact with my product? So one of the better examples from my own experience was when we were building a truck using agile ways of working primarily scrum, and we invited truck drivers.
[16:04] And one of the first increments that we had delivered was the cabin. And it was not like the developers or the product owner sitting in the cabin and telling everyone else how they can see things. We ask the truck drivers to sit in the cabin and share with us to what extent the experience sitting in this cabin is different from their regular truck cabin. So the more you can engage your customers, like a traditional product development, that will be a user acceptance test. But in the review, we’re not asking about acceptance. We just want to learn.
[16:37] And we also want to observe the customer in the environment that we put them into. And the better you can create an environment. Again, look at the review as an experiment. The better the experiment is designed, the more learning you can take from it. So customer being there crucial and then involving them as much as possible, even better.
Victor [16:59]: That makes a lot of sense. When you think about the truck cabin, I think it’s just natural to let people sit in it and say what they think about it. But in software, we kind of have this urge to do demos. We do demos. We show it to people, we screen share. So that’s actually a very fair point.
Sohrab [17:18]: And now think about it. We just have to give them one of these devices and tell them, okay, so try to book, I don’t know, try to book a hotel. If you are running Booking.com, ask your customer, try to book a hotel and then try to filter based on certain categories and try to do this. And then you see how they do it and how intuitive it is to them. And also you will see whether you run into a certain box that you have missed, et cetera. Get the customer engaged as much as possible.
Victor [17:45]: Oh boy, would they learn a lot from that? That’s great. And now to the retrospective, what questions should I ask my team here? Or how would that look like ideally?
Sohrab [17:58]: So again, going back to the intention, the intention is to continuously improve on how we as a group of people, as a team collaborate and deliver value. So there are a lot of things you can now focus on from how we communicate, be it like verbally or also in a written format with regards to requirements, or also other things. How do we engage in conflicts? How do we invite our customers in? How do we build the code? How do we write the code? Like the engineering piece of it.
[18:33] All of these different perspectives can come into a retrospective. Now the crucial thing here is A, providing a space. And that’s what a great scrum master or agile coach, or however you want to call this person does. Create the space where people safe to talk about problems and challenges that they’ve been facing? That’s number one. Secondly, prioritize those challenges and problems and then go into identifying the root causes. Some people use the five Y technique or whatever. And based on those root causes, come up with solutions to these problems.
[19:13] And within each of these steps always focus because ultimately you don’t want to get out of a retrospective with a long list of things that you could do. You want to leave the retrospective with one or two things that you will do, because if you don’t do those things, guess what the problems, the challenges won’t go away by themselves. They’re not just going to disappear. And if you don’t have this habit of identifying problems, identifying solutions, and then executing on those solutions, at some point, people won’t see any value in the retrospectives. Because they will say, oh, we do this every two weeks, we spent an hour or two, we just talk and nothing changes.
[20:00] So what you want is to make the change visible, because that results in improvement. And sometimes everything you try is an experiment. It doesn’t go the way you want. And then you can look in the next retrospective, but built this habit of continuous improvement. And from my perspective, if I have to pick one thing and one thing only, it’s always the retrospective.
Victor [20:25]: And I think you touched on a very, very good point here, which is the scrum master, whose job it is to give people that safe space who probably is, I don’t want to say the only person, but one of the few people who are actually motivated and whose job it is to think about this. And a lot of organizations, especially small, early stage startups, don’t have a scrum master. Actually the product manager equals the product owner equals maybe unintentionally the scrum master, the CEO, potentially the designer or the developer or all of it now. But now we’re getting into too small of a team. But now obviously how important is the scrum master?
Sohrab [21:08] It is important, but for example, in my own company, we’re not that big. We’re a total of nine people, and we are split across multiple initiatives, circles, teams, however you want to call them. Now in a team where I work with one of my colleagues producing content for our online courses, we’re just two people. Do we need also a scrum master, probably not? And we cannot afford it. And that’s the thing that I see in most startups.
[21:37] But what’s important is to understand that somehow we manage to create this space for continuous improvement. And part of that space is taking the time. Another part is to work on things that we as a collective of people become better at addressing these problems. Now, what we decided as a company is on a regular basis, engage with an external coach and work on us as a collective. Some organizations might go and say, actually, we do have the budget to get a scrum master for our whole organization. That’s also great, but not having a scrum master should never be an excuse for not pursuing this journey of continuous improvement.
Victor [22:23]: Now I would like to move on to a topic that I also see is very dear to a lot of people, which is estimations. And I think this is. I mean, this is obviously a can of worms and we could have probably five other shows on this topic alone. But agile comes with its own way of estimating, which is not an hours, even though a lot of people, most people actually still estimate in hours, but there’s the concept of points. Can you explain a bit about that?
Sohrab [22:58]: Yeah. So again, a few steps back, scrum is a framework, just says that items should be estimated. It doesn’t say how and the other agile framework, some of them are more prescriptive. Some of them are less prescriptive, but it’s not necessarily that one could say that agile always estimates in points compared to ours. Now getting into this conversation about points and ours. It’s an interesting one. I personally never understood why people would estimate anything in hours because I mean, I understand why they do it because they want to get some predictability.
[23:36] But the very first time that you do that, and then after a week or two, you look at how close those estimates were. You realize that they’re probably not that close. And you see this with every project and the bigger the projects get, the weirder or the bigger the gap between estimation and reality. So what we try to do is to fulfill the need for predictability. What is the problem that we want to solve? We want to predictably say how much work can be delivered in a certain period of time.
[24:13] Now, especially if you look at a team doing this and not individuals. So again, if you’re just an individual, probably you can estimate in hours, depending on how well you know the task at hand and how well you know your own capabilities. Based on that experience, you could probably estimate in hours, how long it will take you to write a text or whatever, an article. But the moment you think about a team where not everyone has the same skill set. Not everyone has the same seniority, but as a team, you’re now trying to make estimates. The whole concept of hours becomes irrelevant.
[24:53] Now, how do points help us? Points by themselves don’t help us because you still have the uncertainty, like how many points do we get into a sprint, which is a certain period of time, a time box. But once you start estimating in points, which is something that you can really do well as a team, you then built the experience over multiple sprints. How many points did we actually deliver sprint by sprint, by sprint, by sprint?
[25:23] And then based on that, that’s what we refer to as the velocity. You can make predictions into the future. Of course, every time your sprint length changes, those predictions become less reliable. Every time your team composition changes, those predictions become less reliable. So velocity, as a point of experience is only so reliable as the long as you keep things constant, the boundaries being the team and the sprint length, and more or less the type of tasks that they’re working on.
[25:57] So if you take a software team and now ask them to build hardware, the velocity is not going to be any indicator that can help you predict the future. So all of these things taken into consideration the velocity or the point system can help you get the predictability that you ultimately aim for without estimating in hours.
Victor [26:18]: This is great because what you’re essentially doing is taking the hour out of the hour. People are still estimating the very same way as they would with hours. This takes one hour as compared to three hours. So this is three times more complicated takes longer. But then what you can’t do with hours is say that I don’t know, we have a 40 hour week. What you do with velocity is you would say, Hey, we manage 30 hours in 40 hours. That’s essentially what you’re doing with velocity. We’re learning that our team can get an estimated 30 hours done in a week or an estimated 50 hours in a week. And you’re abstracting that away and saying, oh, we’re doing points so that it’s not confusing. Is that basically what it is?
Sohrab [27:04]: It is to some extent. So the example that I give is usually if you go back a hundred years from now and you would ask someone, so I sit in Cologne, the next bigger city is, Bon. How far is it from Cologne to Bon? Probably they would’ve told you. It’s like one day of walking or like half a day on a horse. So instead of like, the distance was measured in time until we came up with the concept of that’s a meter and then thousand meters are one kilometer.
[27:36] Now, does everyone take the same amount of time to go through like a one kilometer race? No, it depends on who that individual is. And it depends also what kind of tools they can use. If you have to run, it depends on who’s the fastest. If you have a car or a bike, the whole thing changes. And the story points to hours are the same thing as kilometers to hours. And velocity is basically how fast can you run within a certain period of time and that’s what we try to do. So take work as a concept and try to put an own dimension behind it that is not time. And then see how much of that dimension can you get into a certain time box?
Victor [28:19]: Yeah, it’s just like in physics, it makes a lot of sense. Obviously when we look back at the first agile software teams, that was most famous for these sticker boards and the posted notes. And that was kind of the new thing. Now, fast forward, a couple of years later, things changed a lot. Even before people started going remote, but now even local teams had to go remote. What tools, especially during maybe discovery, because everybody knows the standard duraboard and Issue tracker. But what tools do you really like that enable scrum in a remote first environment?
Sohrab [29:03]: So anything that fosters collaboration and transparency. So for collaboration, I mean our whole team runs on slack, our developers, they use, I think it’s called [29:13 topo] for pair programming remotely, fosters collaboration. We have mural boards in order to again, create collaboration. You can also take mural, whatever. All of them are essentially the same and we try to create as much transparency as possible. So having a process or a place that on a daily basis, you get together, maybe instead of 15 minutes, now you spend half an hour because you also want to replace the water cooler conversation, et cetera.
[29:42] So any tool that can help foster collaboration and create transparency is super helpful. And once you put those things into place, people can work really well also in a remote session and they can work really agile in a remote fashion, but always ask the people. So I had no idea that there was a tool for pair programming remotely, but when the developers came up with it, Hey, we would like to use it. Alright, go use it. Because the cost of those tools in most cases is really negligible to the overall cost that you have. And the productivity benefits that you get.
[30:16] And this is, I think most startups do this really well because they give people a lot of free around what kind of tools to use, et cetera. Most big corporations where you then have to go through procurement and data security and all of that. For them it’s really difficult to have everyone work remotely and still be productive and collaborative.
Victor [30:38]: And do you have also recommendation on issue trackers, everybody’s kind of in JIRA? Do you have anything else you like, I mean, personally, I think they’ve now gotten a lot better in the last years, but maybe you have something that you like.
Sohrab [30:54] Yeah. I think JIRA is great. For us many years ago we didn’t use JIRA because back then they didn’t have a cloud solution. And as a small company, we didn’t want to have one person being in charge of hosting JIRA. So we selected another tool it’s called pivotal tracker from pivotal apps. It’s super simple to use. It just works out of the box. I don’t know to what extent the functionality between pivotal tracker and JIRA is different or what additional things you would get from JIRA.
[31:23] We’re happy with pivotal tracker and my recommendation to people is always use whatever is already there. The tool is not going to make the difference, using the tool in a systematic and disciplined way and ultimately building on top of it, having the collaboration, that’s going to make the difference. So whatever tool is there, just start with it and don’t worry too much about it.
Victor [31:45]: And what are the most common mistakes people make apart from putting too much focus on the tool?
Sohrab [31:52]: I was just going to say putting too much focus on the tool. So that’s one thing. And the other things are putting too much focus on thinking about how to do things instead of doing things and then learning as you go, I cannot count how many and that again, not so much about startups, but mostly big organizations, how much time they spent on designing the agile initiative rather than just trying to do it with one or two teams and then learning from it.
[32:25] But that goes again, back to the mindset that the people have. They believe if they just spent enough time upfront, they can predict all the things that would come up and design a good solution, but that’s not the case. They hold a lot of assumptions that need to be validated. So moving into doing, into the actual doing, and then learning by doing that’s I think one of the most important thing that organizations need to do, and you can always obsess about like, oh, how should we call this role? And how do we do this?
[32:58] Get into doing Nobody cares about what this is called, but you will learn along the way, how you differentiate between the different roles. And who takes, which kind of decisions. That’s so much more important than all these initial stuff that you do.
Victor [33:15]: That makes a lot of sense. And continuing with maybe mistakes that people make, is a few pain points that I see some of the teams having. So for example when a team just has too many tasks in a given sprint and they’re never able to finish, there’s no way, what would you recommend to them?
Sohrab [33:37]: Take less. So independent from whether you’re working agile or not. This is a disease that we see anywhere and that’s the medical doctor in me speaking. And that disease is called multitasking. We still hold the assumption that we can multitask. None of us can, none of us can, even the ladies listening to this podcast of watching this video, you can’t do it either. We can run multiple things at the same time that we have habits on that drive basically on autopilot, like talking on the phone and cooking. And I mean, everyone’s had probably seen this picture and also vacuuming the carpet, that’s all happening on autopilot.
[34:20] But whenever we consciously want to do something and work is always consciously, especially creative work, which like engineering is part of creative work. We can’t do multiple things at the same time. And every time we switch between different things, we lose productivity due to context switching. One of the first advices that I give to people, recommendations that I give to them is take less, doesn’t mean that you don’t do all of these things over time. Just don’t do them at the same time and you can run so many simple exercises.
[34:58] And for those of you who are interested to see what kind of exercise to run, we have a free online course called agile fundamentals. And maybe Victor, you can take the link to that in your show notes. It’s module five of that course, it’s about Kaban and I run a very simple exercise. It doesn’t take you more than 5 to 10 minutes, and then suddenly you will get to the point where, oh man, what have I done all of these time, like really losing productivity individually as a team and as an organization by taking on too many things at the same time. So advice, number one, take less, focus, stop starting, start finishing. One of the credos of the people working in Kaban.
Victor [35:44]: That’s a very good one. And now when you have a team or let’s say distribute it and the product owner essentially trying to figure out what everybody’s actually working on and when they will actually finish with something certain and that information just isn’t there. What would you recommend or is that almost a disease in itself in wanting to know that very much detailed?
Sohrab [36:10]: I mean, if you really want to know what every single person is working on at any point in time that probably result, or is big based on not a lot of trust within the whole team. And I emphasize on within the whole team, because you cannot only put it on that one person on the product owner, but how do you deal with that? How do you create trust where there is no trust? One of the better things to do is to create transparency and the intention of, for example, a sprint backlog and the intention of the daily scrums is to exactly create that transparency.
[36:44] And based on that transparency that you create, you also create the space for impediments being raised and addressed, and you also create the space for alignment to be created. So really taking these two simple things, a sprint backlog, looking like a Kaban board, by the way, it can help us also with the previous disease that we talked about, like visualizing how many things are happening in parallel, and then reducing that. It can also help you create all of the transparency needed from the product owner side, but also from the side of every other person in that team to see how are we making progress? Where can I help and whom can I ask for help? And based on that become a better team and deliver better products.
Victor [37:32]: And how about when we have lots of bugs or urgent issues that just keep derailing a sprint, just keep coming up and got to put them in there. And here’s my sprint gone. And I probably can’t even finish the complete feature, the outcome that I actually wanted to finish in that sprint.
Sohrab [37:55]: Make it visible, in that sprint backlog, make it visible, like this has come up and this has come up and our servers are down and this. Make it all visible and then make also visible the impact that it has, which is as you mentioned, Victor, we cannot get the features done that we wanted to build in this sprint. And not getting the features done probably we are also not getting the outcomes that we wanted to have as a goal of this sprint.
[38:24] And then talk about it in the retrospective. Is this just a one time thing or have these issues come up over and over and over again? And that probably means that our legacy system is probably a big source of disruption. Now, what are we going to do about this? Are we going to take the time to refactor some of those pieces in that legacy system? Probably yes. It becomes a return on investment calculation. If it’s just a one off, alright, you dealt with it, move on. If it happens constantly, you either create a buffer or you start addressing the root cause of this disruption.
Victor [39:05]: And probably a somewhat similar question is, when I have to keep discussing mid sprint with people, how things should look like if the team is not certain about what is being developed and either discussions come up mid sprint and tasks just get bigger or they have to be just reopened because the product owner realizes this is not what they initially wanted to have developed. What would you tell a team like that
Sohrab [39:37]: To use common sense. We’re laughing but because a lot of teams, again, look at this whole thing as something mechanistic. But in the sprint planning, we said that we will deliver this. Alright, no, during the sprint, in the sprint planning, we have a certain level of visibility and depending on the product that you’re working on, the people that you’re working with, sometimes the weather is a bit more, sometimes a bit less foggy, but it is in general foggy.
That’s what uncertainty feels like. So now we are in the middle of the sprint and now we see that on our most important item, there are a few things that we initially forgot to mention, but without those things, it feels incomplete and it doesn’t really deliver value to our clients. So what do we do? Just because we forgot them initially, we just say, no, no, this is now done. And please open a new ticket so that I can move on to the next one. And then we can talk about this in our next sprint planning. It doesn’t make a lot of sense.
[40:40] That’s where we need to have these individuals and interactions over processes and tools. We talk about it, the product owner says, you know what it would be great if we could do this on top. And the developer says, you know what I can do it. But probably the one item that we have currently at the bottom of our sprint backlog that will fall into the next sprint. And the product owner says, okay, I can live with that. Thank you for letting me know. And that’s the kind of collaboration you want to see mid sprint, and you don’t want to have the debate about, do we open a new ticket or not.
[41:12] Now, depending on the context that you’re in, it is clear why these conversations might come up because you have a product owner, which is the company. Like trying to build a product and then you have a supplier supplying them with developers and they’re being paid based on, I don’t know what, the velocity or whatever. You can take out a lot of these debates if you just say, for example, we’re paying you per sprint. So mid sprint, we don’t have to debate whether this is an initial ticket or not. Because if you’re getting paid by the tickets, you would want this to be an initial ticket.
[41:51] So go back to what is incentivizing different types of behavior and whatever is not an incentive towards better collaboration try to take it out. Create the contract in a way that it fosters collaboration and doesn’t inhibit collaboration. That it fosters building trust to each other. It doesn’t inhibit building that trust, and I’m not a legal expert, but I’ve seen a fair amount of contracts in the past. And some of them really incentivize having these debates instead of delivering value. So that’s my two cents on this.
Victor [42:31]: And that makes a lot of sense. Obviously fixed prices, scrum or agile, don’t really mix well. Thank you so much for this very enlightening episode. It was very, very good to hear your thoughts on this. Where can we learn more about you personally, as well as the scrum academy?
Sohrab [42:49 ] Our company’s scrum academy is the host of a bigger platform, which is called Agile academy. Also easy to remember agile-academy.com, where you not only find the courses and offerings that me and my company offer, but also which a lot of our partners offer both live trainings, online trainings, a hybrid of those things. Because our mission is to make society more productive, more humane and more sustainable. And given the times that we are in, I think this is so much more important than we try to support this journey. That a lot of teams, a lot of organizations and whole societies are on with the knowledge and experience that we have. So just go to agile-academy.com and you will find more about us.
Victor [43:34 ]: Wow. Great. And you were speaking about the scrum master, coaching, training, the scrum master on demand. Is that something your company provides as well?
Sohrab [43:45]: Yes. So we provide the education piece around it. We can also help you with a few coaches that help you in the short run. But our intention with every company that we work with is to not give them our scrum masters for a long period of time, but help them build that capability internally because only that makes it sustainable.
Victor [44:06 ]: Amazing. Thanks for coming on. It was a great show. Sohrab [44:09]: Thank you Victor for hosting me. Great to meet you.
Summary How has the SaaS industry changed and evolved over 20 years? What is the best way to manage people with process? Today’s guest is Alister Esam, Founder of Process Bliss. Despite being a non-technical founder, Alister is a SaaS veteran. He launched his first SaaS in 2003 and then sold it to a competitor […]
Summary In this episode of Product Stories, Victor Purolnik talks to Rajesh Nerlikar, Co-Founder of Prodify, which helps SaaS startup founders, entrepreneurs, recruiters, executives, and product team leads become more product-driven by offering advising, coaching, hiring, and product management services. Episode Highlights/Topics: What made Rajesh go into product? Interest in customer problem space and UX […]
Summary In this episode of Product Stories, Victor Purolnik talks to Vedran Cindrić, Founder of Treblle. If you’ve ever wanted to integrate with another software, had to use an existing integration, built various frontends, or use microservices, then you have or will deal with application programming interfaces (APIs). Episode Highlights/Topics: API Definition: Mechanism that transfers […]
Summary In this episode of Product Stories, Victor Purolnik talks to Mark Colgan, Founder of The Product Onboarders. Mark has audited more than 60 onboarding flows of SaaS companies and shares some of the costliest mistakes made as well as how to avoid them Episode Highlights/Topics: Why audit user onboarding flows? If it’s bad, people […]
Summary In this episode of Product Stories, Victor Purolnik talks to Perry Zheng, a former Amazon, Twitter, and Lyft engineer and founder of Cash Flow Portal. Perry shares how he leveraged his experience working at such successful companies to start his own business building software for real estate syndicators. Episode Highlights/Topics: Cash Flow Portal: Helps […]
Summary In this episode of Product Stories, Victor Purolnik talks to Anthony Joiner, author, coach, entrepreneur, and founder of Blooksy, a Web-based book writing and publishing platform. He explains how he validated his SaaS idea and won $120k in a startup competition. Anthony shares how he came up with the idea, pre-sold the product, developed […]
Summary In this episode of Product Stories, Victor Purolnik talks to Peter Loving, Founder of UserActive, about ways to improve onboarding, increase activation and retention, and when to redesign flows, features, or your entire product. Episode Highlights/Topics: UserActive: UI/UX product design agency for software as a service (SaaS) Technical Side: Understanding frontend programming, development helps […]
Summary In this episode of Product Stories, Victor Purolnik talks to Hannes Kleist, Founder of Stanwood, a German-based but completely remote-first software house. Hannes shares some tips and tricks he uses for remote work, including how to brainstorm as well as align people and hold them accountable. Episode Highlights/Topics: Squads: 3 decentralized, autonomous teams organized […]
Summary In this episode of Product Stories, Victor Purolnik talks to Shruti Bansal, Principal Product Manager at Kpler. Shruti shares her journey of becoming a product manager to build software from scratch that improves commodity trading in the freight industry. Episode Highlights/Topics: Before/After Kpler: From end user building small internal tools to product manager Data […]
Summary In this episode of Product Stories, Victor Purolnik talks to Aggelos Mouzakitis, Growth Product Manager and Customer Researcher at Growth Sandwich, about how a SaaS company’s growth problems – whether it’s customer acquisition, conversion, or retention – might be coming from a weak product vision. How can you improve it to impact your product […]
Summary In this episode of Podcast Stories, Victor Purolnik talks to Idan Yalovich, co-founder of Zest.is, an information enablement tool. Idan shares lessons learned and strategies used to take his company from funding to exit and pivoting from flexible engineering and B2C marketing. Episode Highlights/Topics: What is Zest? Search engine tool to find info all […]
Summary What if there was one thing that will help align your developers, save time and money on engineering, and increase customer satisfaction? It’s real, and it’s called good design. Learn how to use the secret weapon of bootstrapped SaaS founders Lukas Klement and Laure Joumier in today’s episode of Product Stories! Episode Victor: [00:04] […]
Summary If you want to know how to build better software products faster and haven’t learned product management or hired a product manager yet, this episode with Enzo Avigo is for you. We debunk some myths and give you an overview of how product management increases the speed and accuracy of the solutions you develop, […]
Summary How can you validate a SaaS quickly? What’s a good approach to find new SaaS ideas in various niches? Why do some people think too much about SaaS when trying to build a SaaS? Shane White is a developer who runs an entire portfolio of businesses with various cofounders and walks us through his […]
Summary What’s a definitive way to really test your product or landing page hypothesis, see if users understand your value proposition and actually get your onboarding flow? UX testing sounds complicated, but it can be super simple yet very effective. In this episode, Quinn Zeda from Conversion Crimes speaks about why, when, and how to […]
Summary How can your product drive growth, adoption, and market itself? That’s the idea behind product-led growth. Esben Friis-Jensen from San Francisco-based Userflow explains what it means, how it works, and how user onboarding plays a large part in it. Ready to grow your SaaS? Episode Victor [00:12] Welcome to Product Stories. We explore how […]
Summary Have you ever wondered what running an entire team in Eastern Europe is like? Nick Jordan from ContentDistribution is running a 25 people team in Serbia and he is speaking about cultural differences, English fluency, and other things that are good to know when considering hiring in Eastern Europe. Episode Victor [00:29] Welcome to […]
Summary If you’re trying to better understand your customers, better align your internal team and build better products that sell, understand customer journey mapping. Jochem Van der Veer from TheyDo explains how to create and use customer journey maps in the right way. TheyDo is a modern Customer Journey Management Platform that centralizes your journeys […]
Summary If you’re an industry expert wondering how to build a successful SaaS within your niche – get inspired by Amar Ghose who is a non-technical founder sharing the strategies he used to bootstrap a remote-first SaaS with over $100k MRR. Let’s dive in! Episode Victor [00:10] Welcome to Product Stories where we explore how […]
Summary Partnerships and integrations can be the most powerful acquisition channel for any business. David Henzel, who exited MaxCDN a few years ago and today runs a portfolio of various businesses. The fast growth of his businesses has always relied heavily on partnerships and integrations – and today he’s sharing his strategies with us. Episode […]
Summary How to validate SaaS ideas without access to any specific market? By iterating fast and finding an audience through first prototypes. Robin Warren is running a successful suite of Trello integrations for teams and shares his story of gaining early traction without having an audience or market insights. Episode Victor 00:04 Welcome to Product […]
Summary Learn from an experienced startup CTO how to build, validate, and iterate software products FAST. Whether avoiding premature scaling, creating value as soon as possible, and then using the right tools to build scalable software at the right time – Upile Chasowa is sharing the step-by-step approach he used to validate his idea for […]
Summary Overwhelmed by constant communication, unsure how to keep people accountable, and how to plan todos even just for the coming week let alone several months? Anders Thue Pedersen shares with us his very simple TimeBlock methodology that teams use to plan their work, keep themselves accountable and avoid constant coordination. Episode Victor [00:02] Welcome […]
Summary Listen to how Kyle Racki and his co-founders have built a 100-person SaaS business from within an agency. Find out how they come up with the product, validated it, and how they separated resources from ongoing client projects. Learn how he’s managing a 50-person product team, and why they have just completely removed roadmaps […]
Summary Learn how Salesflare is taking on big competitors with a limited development budget, smart prioritization, and a strong core product team. Also, learn more about the Google vetting process they had to undertake to have access to people’s emails. Let’s get into it! Episode Victor: Welcome to Product Stories where we explore how founders […]
Summary How has Craig vetted and acquired a SaaS company as a non-technical founder? How has he embedded it within his existing productized service business? And what is the ShapeUp development methodology which he uses within his remote team? Find out on today’s show! Listen to the episode or read the transcript below. Episode Victor […]