Shashank Singh’s Post

Founder & CEO @ Kroolo | Building Next-Gen AI WorkOS #futureofwork

2mo

How We Built Kroolo So Fast: 5 Do’s and Don’ts from My Journey as a Founder Over the past few months, many people have asked how we managed to build Kroolo so quickly. While I wish there was some hidden secret sauce, a few key principles have stood out—both in what works and what didn't! Here are my top 5 Do's ✅ and Don'ts ❌ for building fast and delivering real value. The Do’s ✅: 1. Learn from Competition / Depth in Clarity (CR= Competitive Research) Speed doesn’t mean shortcuts. From the very start, we had to be crystal clear about the vision, digging into every detail. Check competition like a chess game. Clarity fuels momentum. 2. Detailed Mockups (PX = Product Experience) We didn’t just jump into code. Every feature started as a detailed mockup. Visualizing the product early on helped us avoid missteps, not just what we thought was cool. 3. Role Play ICP in Design (CX = Customer Experience) Our mantra? Always role-play your ICP in product design. When users will navigate the flow, how would they feel? Ask those hard ques.. 4. Product, and Engineering as One Function (DX= Delivery Experience) This was a game-changer for us. We made sure that product, design, and engineering weren't just separate silos but one cohesive function. 5. Make Testing a Culture (TX = Testing Experience) Testing isn’t something you bolt on at the end; it’s part of the DNA. Every assumption, every feature, every experience. It’s not just about catching bugs; it’s about cultivating a mindset of continuous improvement. The Don’ts ❌: 1. Don’t Start Making Assumptions Every time we guessed without data or customer feedback, we stumbled. Trust the process, and always verify. 2. Don’t Be a Manager, Be a Leader Moment you slip into “managing” mode, you lose the agility that’s so crucial. Build a culture where everyone leads, and results will follow. 3.Don’t Analyze Too Much Yes, data is important, but analysis paralysis can kill momentum. We had to learn when to stop analyzing and start executing. Sometimes you need to trust your gut and take the leap. 4. Don’t Wait for Updates Waiting for something to happen is not a strategy. If we needed something done, we didn’t wait for an update—we made it happen. 5. Don’t Avoid Responsibility Everyone at Kroolo owns their outcomes. Responsibility isn’t a burden; it’s the key to moving fast. There's no room for "it's your role!". This journey has been a wild ride—challenging, humbling, and deeply rewarding. Building Kroolo fast wasn’t about shortcuts or hacks; it was about being relentless in our clarity and discipline in what we allowed ourselves to focus on. In the end, it’s not just about speed—it’s about building the right thing, for the right people, the right way. Let’s keep pushing boundaries, together. 🚀

6 Comments

Transcript

Hi guys, shine again today I think. Very interesting topic. I think it was a fun conversation I was having with a bunch of guys. Recently and it was like, you know, very intriguing questions people ask me is, you know, how the hell? And are you able to turn around Shulo so fast? I mean we just matter of months from nothing to a full visible products available for? For commercial consumption, what's your signature recipe of, of doing these things, right? So I think today it's all going to be on the recipe, the recipe or the management style, what I personally felt did resonated with me very, very well, right? So it was a few months back right now the way the funnel way I started doing this is started asking very bold questions to myself. And on the 1st question. Which came to my mind was and is the problem identified and problem again has to be very clearly structured and very clearly fought through in terms of the definition of the problem itself right. And in this case our self was solving the productivity problem at a global level. The second one all question always has been is the problem big enough? Are you kind of solving a smaller bunch of problem or you kind of looking at the broader you know about the more the your. Who cast as more wider a propensity for you to have probably a success to that problem. I think kind of get deep and depends on how you cannot go to the next step towards. So is your problem wide enough and deep enough right. The third thing always has been is generally always works with me is can you quantify the problem? You know, if you can't quantify the problem or we can't measure the problem, then it's a bunch of loose ended questions which you never know where you heading towards right. So you you got to be very sure what you're not what the South. Through east and watch your rest is right so very clearly what you're heading directions are and how you're going to quantify your problem and 4th but I think for me is the most important thing is how the hell you gonna see with this right you may dream anything you may strategies anything. But you know you brought up a very clear clarity in terms of how you're going to execute this right SO24 for only questions start with right at the moment those four things at play right you kind of head to what do you call the path of faster execution and for me I kind of look at what the tool. Those are right, it's what I do and what is don'ts for me, right? So few dos, which I principally follow very, very closely as obviously is 1 is the is the research itself, right? Are you able to have a very clear definition, very clear clarity of the problem? Are you sure exactly sure in terms of how clear are you in terms of approach itself, right. Second product is all about, you know putting the detailed mock up right? So and mock up is all about clarity your customer experience will come aboard itself, right. So how deep and how? Retail is a mockup which kind of gives the very personified experience for your customers itself, right? Third and all, when you kind of mocking up, we kind of designing the product itself, right? You know, how are you able to role play ICP in that, right? The Center for they're not building the product yourself. You're building product for somebody else, right? When you're designing, when you're walking up these things, right? Can you role play your ICP? Think of this as as you kind of transversing between the product itself at a design level itself. Now I should be able to role play. You're in consumer, right fourth, I think for me, it's very, very important is, you know, can you solve a punch everything in one unit itself, disjointed teams, more friction come on board and the ability for you to sort of give up a head start and a quicker way kind of becomes very way longer, right? The way I kind of work this together is I put the product and engineering into just one bucket and you know, these this one function itself was kind of entrusted with three different roles design. Product and engineering and all under the one under the one function itself, right. So cut the cut the chest and making sure that you know, you kind of heading the product sort of output very, very fast, right? Very, very important is, you know, testing as a culture, because a lot of times people put so much of thought in terms of pure engineering, but forget about what what testing Center for that that last mile, last mile is very important to get the best in class of product experience, right. With testing should be a culture that cannot be an extended function. Some of the factors are tones which I personally never liked in the organization. The 1st is start making assumptions right? Assumption is exact opposite to the clarity, right? So as much as possible shorten your assumption cycles, hopefully minimize as much as possible right? The second, somebody being a manager manager. They feed the purpose of getting yourself sort of warmed up, right? Everybody had been hands down. Everybody should be into this together, right? Everybody has a role to play fast organizations. You know, there is no room for being a manager, right, So you have to be an effective doer and execution in our respective roles you play. Third thing I think which I always observe is don't analyze too much. You need to have some level of intelligence of the way they're moving ahead and start sort of, you know, on all your your execution as fast as possible right now, obviously. Does get long you may poop or the certain things you may jump off certain things itself, you might fail as in between us. So that's OK. That's part of the journey, etc, right. But the moment you kind of analyzing and delaying that opportunity costs as far as possible, right For you, it's a delayed realistic output for your journey itself, right? So goal post is defined length and sooner you kind of achieve that, which means that the way you kind of go with certain level of analysis, but not too much. The next is I think waiting for. I mean, I, I hate personally that people says I'm waiting for an update. That's why don't you jump in, ask exactly what's going on. Lastly, I think it's about, you know, when people start questioning, saying that it's your role. Kind of gets me off the hook. What is your role? Is everybody's role, right? Everybody's in this together, everybody and it's sometimes is that I would love to have somebody will say this now I'll do this. I can own this right. The moment the culture of multi hair in the culture of doing together and culture of saying I will own it and kind of brings that organization to a very, very next level itself, right, And I would love to have your feedback on this now you felt and how you kind of set up your organization. Itself, right. And what do you think you know should be, should be any specifications around that?

Founder & CEO @ Reya Health | Angel Investor | Serial Entrepreneur

2mo

I completely agree that learning from competition and having clarity on the vision is important. I love the emphasis on role-playing the ICP in product design and making testing a culture.

Accelerating Business Growth for SheerID, HubSpot, and Pump.co | CRM and Market Expansion Expert | Entrepreneur | Author | India Market Entry Specialist

2mo

Can’t agree more

Veejay Madhavan

Veejay Madhavan

I accelerate your delivery of profitable and sustainable growth, harnessing Gen Z talent and AI to create sustainable high-performing teams. Proven track record and recognized thought leadership.

2mo

Shashank Singh , well articukated. Thanks for sharing your journey.

2mo

🎯😁

Software Engineer |Innovative Technical PM | Jira & Atlassian Expert | AI & ML Product Leader | GenAI & AR Innovator | Chatbot & Robotics Solutions Architect | IoT & FinTech Strategist | AWS & Azure | Agile Coach

1mo

Outstanding recommendations

Data Analyst | EXCEL, Python , MY SQL , POWER BI, Machine learning

2mo

Great journey

See more comments

To view or add a comment, sign in

More Relevant Posts

Chris LaFlamme

Kroolo - AI Project Creation | Founding Account Executive @ Kroolo Software | AI | SaaS | Project Management Software
2mo Edited
Report this post
Curious how Kroolo came to be so quickly? Check out the story straight from our Founder & CEO, Shashank. #Kroolo #Startup

Shashank Singh

Founder & CEO @ Kroolo | Building Next-Gen AI WorkOS #futureofwork
2mo

How We Built Kroolo So Fast: 5 Do’s and Don’ts from My Journey as a Founder Over the past few months, many people have asked how we managed to build Kroolo so quickly. While I wish there was some hidden secret sauce, a few key principles have stood out—both in what works and what didn't! Here are my top 5 Do's ✅ and Don'ts ❌ for building fast and delivering real value. The Do’s ✅: 1. Learn from Competition / Depth in Clarity (CR= Competitive Research) Speed doesn’t mean shortcuts. From the very start, we had to be crystal clear about the vision, digging into every detail. Check competition like a chess game. Clarity fuels momentum. 2. Detailed Mockups (PX = Product Experience) We didn’t just jump into code. Every feature started as a detailed mockup. Visualizing the product early on helped us avoid missteps, not just what we thought was cool. 3. Role Play ICP in Design (CX = Customer Experience) Our mantra? Always role-play your ICP in product design. When users will navigate the flow, how would they feel? Ask those hard ques.. 4. Product, and Engineering as One Function (DX= Delivery Experience) This was a game-changer for us. We made sure that product, design, and engineering weren't just separate silos but one cohesive function. 5. Make Testing a Culture (TX = Testing Experience) Testing isn’t something you bolt on at the end; it’s part of the DNA. Every assumption, every feature, every experience. It’s not just about catching bugs; it’s about cultivating a mindset of continuous improvement. The Don’ts ❌: 1. Don’t Start Making Assumptions Every time we guessed without data or customer feedback, we stumbled. Trust the process, and always verify. 2. Don’t Be a Manager, Be a Leader Moment you slip into “managing” mode, you lose the agility that’s so crucial. Build a culture where everyone leads, and results will follow. 3.Don’t Analyze Too Much Yes, data is important, but analysis paralysis can kill momentum. We had to learn when to stop analyzing and start executing. Sometimes you need to trust your gut and take the leap. 4. Don’t Wait for Updates Waiting for something to happen is not a strategy. If we needed something done, we didn’t wait for an update—we made it happen. 5. Don’t Avoid Responsibility Everyone at Kroolo owns their outcomes. Responsibility isn’t a burden; it’s the key to moving fast. There's no room for "it's your role!". This journey has been a wild ride—challenging, humbling, and deeply rewarding. Building Kroolo fast wasn’t about shortcuts or hacks; it was about being relentless in our clarity and discipline in what we allowed ourselves to focus on. In the end, it’s not just about speed—it’s about building the right thing, for the right people, the right way. Let’s keep pushing boundaries, together. 🚀
Like Comment
To view or add a comment, sign in
Bilal Abdelilah

Empowering B2B SaaS Founders | No-Code Development to Launch Your Ideas Faster | Custom Solutions Without Coding
1mo
Report this post
"Should I build an MVP?" Wrong question. "How can I validate my idea fastest?" Now we're talking! Let me break down what a Minimum Viable Product really is (spoiler: it's probably not what you think). Here's the deal: An MVP isn't a cheaper version of your final product. It's a learning tool. Why? Because here's what typically happens: You have this brilliant idea You talk to potential customers They say "Oh yeah, that sounds amazing!" You spend months building Launch day comes and... crickets Truth bomb: People lie. Not because they're mean, but because they want to be nice. Or they think they'll use your product, but when it comes to actually paying... that's a different story. This is where MVPs come in. Two ways to build one fast: Human-Powered MVP 🤝 Look automated, run manually Use VAs or manual work behind the scenes Gather real usage data Test if people will actually pay No fancy tech needed - just a Google Sheet and some elbow grease! No-Code MVP 🛠️ Quick to build Easy to modify Perfect for validation Minimal investment Here's what you DON'T need in your MVP: Fancy billing systems (Venmo works!) Password reset features Automated everything Perfect design Delete buttons (you can do it manually) The real question isn't "Is it ready?" It's "Does this solve the absolute minimum pain point someone will pay for?" My rule of thumb? If you can't build your MVP in 1-2 weeks, you're probably overthinking it. Remember: The goal isn't to build the perfect product. It's to learn if you're solving a real problem people actually care about (and will pay for!). P.S. Stuck on your MVP? DM me your situation . Let's figure out the fastest way to validate your idea!
Like Comment
To view or add a comment, sign in
Systaldyn Consultancy Private Limited

156 followers
5mo Edited
Report this post
When building a software product, it's easy to get caught up in concerns about low quality, lengthy development times, or the challenges of hiring the right staff. However, the most significant risk is often overlooked: creating a well-made product that no one wants to buy. Before diving into full-scale development, the essential first step is demand validation. This means ensuring that there is a market for your product before investing time and resources into building it. Validating demand can save you from the costly mistake of developing a product that has no buyers. Here are four popular techniques for demand validation: 1. Landing Page Test: Create a single web page that describes your product concept and gauge interest by tracking how many visitors sign up for more information. This can give you a clear indication of market demand. 2. Wizard of Oz: Develop a fake front-end interface that looks and feels like the actual product, but manually perform the backend processes yourself. This allows you to test user interest and usability without building the full product. 3. Explainer Video: Produce a video that demonstrates your product idea and its potential benefits. Share this video and ask viewers to sign up for early access if they are interested. This can help you measure interest and collect potential customer feedback. 4. Single Feature MVP: Instead of building a full-featured product, focus on developing just one core feature. This allows you to test the market with minimal resources and refine your product based on user feedback. In summary, demand validation helps reduce the risk of building a product that no one wants by testing the market interest before you commit to full-scale development. #ProductDevelopment #StartupTips #DemandValidation #MVP #Innovation #TechEntrepreneur #SoftwareDevelopment
Like Comment
To view or add a comment, sign in
Headway - Digital Product Agency

2,746 followers
10mo
Report this post
Everyone has a different opinion of what an MVP is for products. What's yours? Billy Sweetman, our Head of Design put together his thoughts on every aspect of minimum viable product process and how we think about them at Headway. What doe he specifically cover in the video? Here's all the timestamps for the curious ones out there. 00:00 - Introduction 02:53 - What is an MVP? 05:33 - MVP App Examples 07:22 - Planning Your MVP in 4 Steps 08:36 - Types of MVP 10:15 - MVP Metrics 11:04 - MVP No Code Tools 12:08 - Budget and Resource Management 13:25 - Talking to Customers 14:38 - Mapping Opportunities 16:35 - Getting Rid of Pet Features 17:31 - Write a Brief 17:54 - Service Blueprint 19:12 - App Mapping 20:12 - Setting Boundaries 25:12 - Document Learnings 26:35 - Problems with Funding to Build an MVP 28:11 - Using AI to Build an MVP 33:34 - Using Figma Prototype as MVP Watch the video on YouTube https://lnkd.in/guj7XeW5

Don't Build an MVP Without These Tools - The Importance of Mindset for Minimum Viable Product

https://www.youtube.com/
Like Comment
To view or add a comment, sign in
Adam Reynolds

Storyteller | Innovator | Senior Product Manager | Solution Architect | Marketeer | Low Code Evangelist | React Developer?
7mo
Report this post
What’s the difference between a tool and a product? It feels like the setup to a bad joke. But it’s not. There’s a distinct difference. In software terms a tool is a set of functionality built to cater for a specific purpose. There’s no beginning or end in mind; it just exists to do the thing. Rick and Morty highlighted this premise perfectly when rick built an intelligent robot at the breakfast table for a single purpose. 🤖 : “What is my purpose?” Rick: “You pass butter.” 🤖 : *existential crisis* That robot was a tool. A means to an end. It had no purpose outside of passing the butter. A product is more than that. Like a good story it has a beginning a middle and an end. If you want to build a good product you’ve got to have the whole story. 🪝 A hook to get customers into the story. 📖 A plot to keep the customer reading. 🥳 An end that leaves them feeling both accomplished and wanting to read it again... and again… and again… Don’t just pass the butter. #product #productmanagement #design #storytelling #passthebutter
Like Comment
To view or add a comment, sign in
Canny

12,821 followers
9mo
Report this post
Building a new product? Here's a guide that can help you. You don't have to follow the whole process. But maybe this will give you some ideas to improve yours? Check it out ⬇️ 👨💻 https://bit.ly/48wTC9C

Mastering the new product development process - Canny Blog

https://canny.io/blog
Like Comment
To view or add a comment, sign in
Headway - Digital Product Agency

2,746 followers
6mo
Report this post
How much design or code is enough for an MVP product? What types of MVPs can you create, and when do they make sense? Billy Sweetman shows you how to create a strategy to leverage MVPs in different parts of the product journey. ▶️ Segments in the Video: 02:53 - What is an MVP? 05:33 - MVP App Examples 07:22 - Planning Your MVP in 4 Steps 08:36 - Types of MVP 10:15 - MVP Metrics 11:04 - MVP No Code Tools 12:08 - Budget and Resource Management 13:25 - Talking to Customers 14:38 - Mapping Opportunities 16:35 - Getting Rid of Pet Features 17:31 - Write a Brief 17:54 - Service Blueprint 19:12 - App Mapping 20:12 - Setting Boundaries 25:12 - Document Learnings 26:35 - Problems with Funding to Build an MVP 28:11 - Using AI to Build an MVP 33:34 - Using Figma Prototype as MVP https://lnkd.in/gts6K-Pi

Don't Build an MVP Without These Tools - The Importance of Mindset for Minimum Viable Product

https://www.youtube.com/
Like Comment
To view or add a comment, sign in
Mikail Bayram

We’ll Build Your Idea Into a Software Product in Just 6 weeks! I Guaranteed or Your Money Back! I Worked on 20+ Products From Scratch to Market I 8+ Years of Experience.
6mo
Report this post
MVP vs Prototype: What You Need to Know In the world of product development, there's often confusion around the differences between a minimum viable product (MVP) and a prototype. While related, they're not quite the same thing. What do they really mean? And more importantly, how do they differ? Here's a quick breakdown to clear the confusion: -> Prototype <- Purpose: To test and validate the design and functionality of a product or feature. Key Features: • A visual representation or mockup of your idea. • Focus on the user interface, user experience, and overall look and feel. • Often non-functional or partially functional. • Used for internal testing and gathering early feedback from a small group. -> MVP (Minimum Viable Product) <- Purpose: To test the viability of your product in the real world and gather user feedback. Key Features: • A working version of your product with basic, core features. • Released to a limited audience (early adopters, beta testers). • Used to collect data on user behavior, preferences, and willingness to pay. Think of it like this: • Prototype: A sketch of your idea on a napkin. • MVP: A basic version of your product built from that sketch. When to Use Each: • Prototype: Early in the development process, when you're still exploring design concepts and user flows. • MVP: When you're ready to test your product in the real world and start gathering data on its viability. So, if you're working on a new product idea, make sure you understand whether you need: a prototype to validate the UX first or if you're ready to start developing that MVP to validate product/market fit. --- Want to build your MVP or dive deeper into any of these steps? 👉 DM me word "MVP". --- Follow Mikail Bayram for actionable tips, real-world examples, and lessons learned from building 15+ products from scratch.
18 Comments
Like Comment
To view or add a comment, sign in
Netguru

50,517 followers
6mo
Report this post
You might have the greatest idea in the world but if it takes you ages to bring it to the market, you’ll lose to a worse idea – just one with better timing. A few years ago Clayton Christensen dropped a bombshell on the business world: out of 30,000 apps launched each year, 95% fail. Does that mean you should give up on your hot idea? Not necessarily. One key success factor is how quickly you can bring your app to the market. Start collecting feedback from customers and iterate based on what the market wants. Why is reducing time to market crucial? 1. Cutting the time to launch means fewer companies to fight for user attention. 2. The sooner you launch, the earlier you’ll see a return on investment. 3. Tech enthusiasts can provide valuable feedback to improve your product. 4. Being early with a high-quality product helps you stand out. But there are three factors that influence TTM: Product complexity, resource availability, and regulations. Here are 7 ways you can reduce TTM: 1. Work with a skilled team to develop a Minimum Viable Product (MVP) quickly. Focus on market research and user feedback to ensure you’re on the right track. 2. Utilize AI tools like GitHub Copilot and Locofy.ai to suggest code, catch bugs, and optimize designs. 3. Use a single codebase for multiple operating systems to save time and resources. 4. Use low-code/no-code for rapid prototyping and iteration, which reduces development time by over 50%. 5. Implement Agile methodologies to deliver products iteratively and respond quickly to customer feedback. 6. Optimize workflows with detailed documentation, clear timelines, and transparent communication. 7. Swiftly add necessary talent to your project on a temporary basis. By leveraging these strategies, you can bring innovative products to market faster and more efficiently. Remember, it's better done than perfect – focus on speed and iterate later. https://lnkd.in/dt7GYx8r

7 Ways to Achieve Faster Time to Market

netguru.com
Like Comment
To view or add a comment, sign in
Anh Nguyen

I help startups build a full-code Minimum Viable Product in 90 days | Providing instant 4+yoe developers to scale up your tech team | Saving 3x time on development & tech hiring
5mo
Report this post
The fastest way to go bankrupt as a founder Build without idea validation So, how to validate your ideas fast and cost-saving? Pick one of the strategies below: 1. Landing page → Set up a simple page that looks sexy → Convey the core values you offer → Evoke curiosity like a movie teaser → Make it easy to understand within 10 seconds → Ask readers to subscribe with email addresses → Give expectations when the app will be ready 2. Wizard of Oz → Show customers a fake complete product → But behind a curtain, the entire work is done manually → To end-users, automation or manual doesn’t matter → As long as their pains are solved 3. Single-feature MVP → Focus entirely on just one painkiller feature → To solve only one problem → For one target audience → To narrow down the market and release faster Success story: → Buffer crafted a simple landing page → Next, they added plans & pricing info → To signup, users had to view pricing plans, then picked one of them → They only built once the number of subscribers was good → Now they made $18.1M in 2023 Do you recommend any other good tactics for fast validation?
14 Comments
Like Comment
To view or add a comment, sign in

Shashank Singh

13,667 followers

View Profile Follow

More from this author

Explore topics