Podcasts about product habits

What are some of the habits that product people have? After reading two books on habits recently, that thought kept coming up. This episode goes into the idea of Product Habits, those things that we do with our teams, customers, company, products, and ourselves. Andrew Stokzko joins the show to discuss his ideas and experience. Got a good or bad habit you want to share with us? Feedback: twitter - @deliveritcast  email - deliveritcast@gmail.com Support: Product Coaching and Consulting - seek taiju  Support - Buy me a Coffee  Links: Andrew Skotzko @askotzko Make things that matter - Podcast Andrew Skotzko - How to know if you're interviewing at a product-led company  James Clear - Atomic Habits  BJ Fogg - Tiny Habits  Toby Sinclair - Tiny Habits vs Atomic Habits, Which should you read?  Sachin Rekkhi - Atomic Habits for Product Managers  Rich Mironov - Prioritization is a Political Problem as Much as an Analytical Problem   

This episode of Tradeoffs is a big one.Hiten Shah, co-founder of FYI and Product Habits, and ProfitWell's Patrick Campbell are tearing down the two biggest players in office productivity software: G Suite and Microsoft Office 365. With 36 years of experience and more than 180 million active monthly users, Office 365 dominated the market for more than 20 years. Going up against the only major player in the market must have seemed like a formidable task when G Suite came on the scene in 2006, but its native cloud platform is now Office 365's major competitor.This is a ProfitWell Recur production—the first media network dedicated entirely to the SaaS and subscription space. 

On the show today is Hiten Shah. Where do I start with Hiten... most notably he's the founder of the software companies FYI, Crazy Egg, and KISSmetrics. He's also been involved in starting a number of other companies. He writes a newsletter called Product Habits. He does a podcast called The Startup Chat. He angel invests. He has a grand career in tech.I wanted to bring him on because Hiten has been in the world of tech and startups for a long time. And with time and experience comes wisdom. I'm always impressed by the way that Hiten sees the world and how he thinks about marketing. He also has a unique ability to be very objective and honest about himself. We get into this with his companies but he's not afraid to talk about where things have fallen short. And given his experience with Crazy Egg and KISSmetrics, Hiten knows what works and doesn't work — he's seen it all and has been on the forefront of marketing for a long time.You'll hear about what go-to-market model Hiten would start with if he was founding a new startup today, why marketing is everyone's job, why all of his landing pages are just a headline, subheadline, call to action, and some sort of illustration, and why there's no such thing as having done zero marketing.More on Hiten: @hnshah on Twitter FYI The Startup Chat podcast Sponsored by SparkLoop — the referral tool for newsletters. Hundreds of smart newsletter creators use SparkLoop to get more, high-quality email subscribers on autopilot. Get started in 5 minutes and start a free 30-day trial → sparkloop.app/eim

Camille Ricketts is CMO at Notion. In this episode we're talking about how Notion built a multi-billion dollar brand by humanizing enterprise marketing. Camille was the first marketing hire at Notion and she explains how B2B SaaS enterprise marketing doesn't need to be stiff, boring, and overly-formal but just real, authentic, and human. This approach has helped Notion build a brand valued at over 2 billion dollars with a team of less than 10 marketers within a 50-person company. In this episode, we discuss: - How Notion segments its customer base - How they do enterprise marketing and the shift they're driving towards the consumerization of the enterprise - Notion's approach to brand building, storytelling & crafting their brand voice - The tactics & channels that are working for Notion's marketing team today - How Notion's marketing team measures success Links Notion >> https://www.notion.so/ Obviously Awesome by April Dunford >> https://www.goodreads.com/en/book/show/45166937-obviously-awesome The Culture Code by Daniel Coyle >> https://www.goodreads.com/book/show/33517721-the-culture-code Hiten Shah's Product Habits >> https://producthabits.com/blog/ Figma >> https://www.figma.com/ --- Advance B2B >> www.advanceb2b.com Follow The Growth Hub on Twitter >> twitter.com/SaaSGrowthHub Follow Edward on Twitter >> twitter.com/NordicEdward

Hiten is a prolific SaaS founder of companies including Kissmetrics and Crazy Egg and is now working on FYI. He also runs Product Habits to help other founders develop the habits they need for success. In this episode, Hiten shares: His framework for identifying product ideas worth pursuing, How to identify what your customer really want. What Hiten has learned from David Cancel about different go to market strategies. Why continuous testing drives increased product value. Resources Product Habits Building an MVP for FYI in 5 days Reaching out to Hiten Reach out on Twitter or sign up for FYI

Today is a very special episode as we are celebrating our first anniversary of Churn.FM. We have now published a new episode every week for 52 weeks straight and what better way to celebrate the anniversary than by having the guest of our very first episode back on the show! This week we have Brian Balfour, Founder, and CEO of Reforge. Reforge have Career Development Programs for Experienced Tech Professionals in Product, Marketing, Data, Design, and Engineering co-authored by Brian Balfour, Andrew Chen, and Sean Clowes.In this episode, Brian shared his new learnings on churn and retention since our last chat a year ago, why understanding your customer's habits are important to improving user activation, and a deep dive into the concept of survival analysis. Brian also shared his insights on why you should focus on a specific user activation flow, the importance of a vendor-champion relationship, and why jumping into quantitative data too fast can be misleading.It has been a year, and as usual, I'm always excited to hear what you think of this episode, and if you have any feedback, I would love to hear from you. You can email me directly on Andrew@churn.fm. Don't forget to follow us on Twitter

Today we're going to learn about the skills accumulated and lessons learned from a great marketer throughout the various stops in his career. Joining us today is a titan of modern marketing, Hiten Shah. Hiten is a serial entrepreneur and founder of marketing analytics, collaboration and visualization companies like KISSmetrics, Crazy Egg, and his current project, FYI, which is a tool that helps teams search and organize all of their documents in one place. In addition to his operating roles, Hiten is the creator of Quick Sprout marketing blog, The Startup Chat Podcast, and he's an advisor to over 50 startups. Show NotesConnect with:Hiten Shah: Website // LinkedInThe MarTech Podcast: Email // LinkedIn // TwitterBenjamin Shapiro: Website // LinkedIn// TwitterSee Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Today we're going to learn about the skills accumulated and lessons learned from a great marketer throughout the various stops in his career. Joining us today is a titan of modern marketing, Hiten Shah. Hiten is a serial entrepreneur and founder of marketing analytics, collaboration and visualization companies like KISSmetrics, Crazy Egg, and his current project, FYI, which is a tool that helps teams search and organize all of their documents in one place. In addition to his operating roles, Hiten is the creator of Quick Sprout marketing blog, The Startup Chat Podcast, and he's an advisor to over 50 startups. Show NotesConnect with:Hiten Shah: Website // LinkedInThe MarTech Podcast: Email // LinkedIn // TwitterBenjamin Shapiro: Website // LinkedIn// Twitter

Cette semaine, on continue la série sur l'ebook d'Hiten Shah sur la création de meilleurs produits. Cette fois, on parle du processus d'amélioration continu du produit. Chaque lundi, Systemator vous délivre des retours d'expérience, de l'inspiration, des outils et des conseils pratiques pour aider les entrepreneurs à développer leur créativité, leur productivité et leurs revenus. Vous venez d'activer le Systemator ! Installez-vous confortablement dans votre nouvelle vie de créatif. Mentionné dans l'épisode : - Product Habits (et l'ebook) :  https://producthabits.com/  - Product Hunt :  https://www.producthunt.com/  - Victor Ferry :  https://www.youtube.com/channel/UCcueC-4NWGuPFQKzQWn5heA 

This week on Product Love, I talked to Hiten Shah, co-founder of FYI, Product Habits, KISSMetrics and Crazy Egg, about feature adoption and retention.

Cette semaine, Sébastien & Wesley vous parlent de l'ebook de Hiten Shah, les 5 habitudes pour créer un meilleur produit. Dans cette épisode, on vous livre la première bonne habitude : toujours commencer par le client. Chaque lundi, Systemator vous délivre des retours d'expérience, de l'inspiration, des outils et des conseils pratiques pour aider les entrepreneurs à développer leur créativité, leur productivité et leurs revenus. Vous venez d'activer le Systemator ! Installez-vous confortablement dans votre nouvelle vie de créatif. Mentionné dans l'épisode : - Product Habits (et l'ebook) :  https://producthabits.com/  - Product Hunt :  https://www.producthunt.com/ 

In this episode of Recur Now, we dive deep into the future of female funding with Marie Prokopets of FYI & Product Habits.

What struck me most when talking with Hiten was the clarity of his thinking and his honesty/transparency. The beginning of the conversation went in a unique direction, and I'm glad it did as it allowed us to discuss some of the more nuanced and complex dynamics that arise when building businesses from nothing. Hiten has been in this industry and creating products for many years; he spoke to the evolution of his thinking in many areas, including giving advice, pressure and removing mental/emotional road blocks instead of breaking them. We of course talked about remote work in depth. Having built many different distributed teams, both self-funded and vc backed, Hiten has some interesting and valuable insights when it comes to remote teams. This was one of our most interesting and in depth conversation with a leader in the remote work space. I hope you enjoy it as much as we did! Hiten's current company, FYI, is working to solve one of the major issues of remote work by making it easier to access and organize documents. You can check what he and his co-founder Marie Prokopets have built at usefyi.com. Also, be sure to check out their Remote Work Report, one of the most comprehensive handbooks to all things remote work, and one that we were lucky enough to contribute to! And of course, follow Hiten on Twitter: @hnshah The book that Hiten would force everyone to read: The Courage to be Disliked by Alfred Adler

Welcome to the first-ever episode of Tradeoffs, where Hiten Shah (of FYI and Product Habits) and Patrick Campbell (of ProfitWell) talk through the product decisions of popular companies and the potential tradeoffs they made as a result. They break down how these choices shaped the growth of these companies and what it means for their future. Starting it off is their conversation about online streaming juggernaut Netflix.

This week on DisrupTV, we interviewed Hiten Shah, Co-Founder of FYI, Product Habits and Crazy Egg, Betty Ng, Author of PO-LING POWER, Speaker, and Tech Entrepreneur, and Esteban Kolsky, Principal & Founder at ThankJar. DisrupTV is a weekly Web series with hosts R “Ray” Wang and Vala Afshar. The show airs live at 11:00 a.m. PT/ 2:00 p.m. ET every Friday. Brought to you by Constellation Executive Network: constellationr.com/CEN.

This week on Product Love, I talked to Hiten Shah, co-founder of FYI, Product Habits, KISSMetrics and Crazy Egg, about feature adoption and retention.

This is episode 14 and today I have Hiten Shah. I invited Hiten because he is a true serial entrepreneur. Hiten Shah is the co-founder of numerous successful SaaS companies, including FYI (helps you find your documents in 3 clicks or less), Crazy Egg (creates heatmaps for your website), Product Habits (content and education for Product teams), KISSmetrics, and others. He has also advised or invested in over two dozen technology startups. In this candid conversation, Hiten touches on: How he is able to start, juggle and be successful with multiple companies How his marketing teams operate How to compete as a marketer in a very crowded & noisy digital marketing landscape Hiten is an entrepreneur that’s been at it for over 15yrs. He knows what he’s talking about. I really enjoyed speaking with Hiten, I hope you find it helpful. On to the show.   Links: Hiten on LinkedIn Hiten on Twitter FYI, Hiten's Latest Startup   I'd like to hear from you: What topics should we cover? Send me an email or reach me on Twitter @marcbitanga Did you like the episode? Rate it or submit a short review.   Connect with me: On LinkedIn On Twitter @marcbitanga On Instagram @marcbitanga

In episode #1020, we discuss Neil's billion dollar mistake. Tune in to hear where Neil went wrong. We have committed to throwing a FREE Marketing School Live Event in Los Angeles. Check out the details on this website if you would like to attend. Remember: we are capping the event at 500 people, so sign up now, if you're interested! DM Eric if you would like to participate in the VIP dinner. TIME-STAMPED SHOW NOTES: [00:27] Today's Topic: Neil's Billion Dollar Mistake [00:40] Kissmetrics was part of the mistake. [01:05] Neil's former partner broke down their mistake in a blog post on Product Habits. [01:28] They built a product they thought was needed. [01:40] They learned no matter what you build, people don't want to pay for things. [01:55] Version 2 required too much customization. [02:40] They found people couldn't get a lot of value out of their Google Analytics. [03:05] Neil and his partner just needed to find what the gaps were, but it took them too long. [03:50] Kissmetrics feel behind the crowd. [04:10] They would often change directions, which was not a good idea and not great for the team. [04:30] They should have executed quickly, but they didn't or couldn't. [05:20] Neil thinks they made too many mistakes. [05:30] The biggest issue was a class action litigation. [06:00] They can only blame themselves. [06:04] They spent too many years building the wrong product and didn't know how to innovate. [06:06] That's it for today! [06:17] Don't forget to check out Single Grain for more info about our free live event in June. Leave some feedback: What should we talk about next? Please let us know in the comments below. Did you enjoy this episode? If so, please leave a short review. Connect with us: NeilPatel.com Quick Sprout Growth Everywhere Single Grain Twitter @neilpatel Twitter @ericosiu

In episode #1020, we discuss Neil’s billion dollar mistake. Tune in to hear where Neil went wrong. We have committed to throwing a FREE Marketing School Live Event in Los Angeles. Check out the details on this website if you would like to attend. Remember: we are capping the event at 500 people, so sign up now, if you’re interested! DM Eric if you would like to participate in the VIP dinner. TIME-STAMPED SHOW NOTES: [00:27] Today’s Topic: Neil’s Billion Dollar Mistake [00:40] Kissmetrics was part of the mistake. [01:05] Neil’s former partner broke down their mistake in a blog post on Product Habits. [01:28] They built a product they thought was needed. [01:40] They learned no matter what you build, people don’t want to pay for things. [01:55] Version 2 required too much customization. [02:40] They found people couldn’t get a lot of value out of their Google Analytics. [03:05] Neil and his partner just needed to find what the gaps were, but it took them too long. [03:50] Kissmetrics feel behind the crowd. [04:10] They would often change directions, which was not a good idea and not great for the team. [04:30] They should have executed quickly, but they didn’t or couldn’t. [05:20] Neil thinks they made too many mistakes. [05:30] The biggest issue was a class action litigation. [06:00] They can only blame themselves. [06:04] They spent too many years building the wrong product and didn’t know how to innovate. [06:06] That’s it for today! [06:17] Don’t forget to check out Single Grain for more info about our free live event in June. Leave some feedback: What should we talk about next? Please let us know in the comments below. Did you enjoy this episode? If so, please leave a short review. Connect with us: NeilPatel.com Quick Sprout Growth Everywhere Single Grain Twitter @neilpatel Twitter @ericosiu

Welcome to another Antifragile episode. Joining us today is Hiten Shah. Hiten started multiple SaaS companies since 2005 and is an active advisor and investor. He is a co-founder of Product Habits, Crazy Egg and FYI. The conversation is very basic: if there is a problem, how are we going to deal with it Talking about challenges, there is nothing more monumental for Hiten than the lawsuit that the company had to deal with. Hiten shares how he and his co-founder were able to work together alongside with their lawyers in solving the problem. You have to be objective of what do you need to make the business successful Hiten talks about the importance of getting past emotions in solving problems. He also warns about false beliefs and false positives which most founders fall into. Founders must be objective in knowing what they need for the business to move forward and be successful. We then get an overview about Draft Send and FYI and how they solve the real problem in the document space. Episode Quotes "The conversation is very basic, if there is a problem, how are we going to deal with it" "The best thing you can do is have a plan and have milestones and execute towards the plan" "Whatever strategies I have they all have to do with getting past emotion" "My companies are not my babies. That's not how I think about them. I am not attached to them in that way" "We usually know the answer to our problems too" "You have to be objective of what do we need to make this business successful" "If you're not happy, figure out why you're not happy and just solve it" Listen to Learn 00:25 Getting to know Hiten Shah05:29 Hiten's make-it-or-break-it moments, lawsuit story12:01 Going forward and solving the problem18:20 How Hiten developed his problem solving skill?20:31 Defining clear goals & strategies, and implementation25:23 Overcoming emotions in problem solving27:41 Who gave you the most valuable advice?29:25 Learning from experience, false beliefs and false positives35:45 The problem in the document space, overview about FYI37:55 Determining false positives, importance of being objective40:37 Rapid Fire Questions42:34 Links and Announcements

Sponsored By Knit. Today we're going to learn about the skills accumulated and lessons learned from a great marketer throughout the various stops in his career. Joining us today is a titan of modern marketing, Hiten Shah. Hiten is a serial entrepreneur and founder of marketing analytics, collaboration and visualization companies like KISSmetrics, Crazy Egg, and his current project, FYI, which is a tool that helps teams search and organize all of their documents in one place. In addition to his operating roles, Hiten is the creator of Quick Sprout marketing blog, The Startup Chat Podcast, and he's an advisor to over 50 startups. Episode TranscriptConnect with:Hiten Shah: Website // LinkedInThe MarTech Podcast: Email // LinkedIn // TwitterBenjamin Shapiro: Website // LinkedIn// TwitterSee Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Sponsored By Knit. Today we're going to learn about the skills accumulated and lessons learned from a great marketer throughout the various stops in his career. Joining us today is a titan of modern marketing, Hiten Shah. Hiten is a serial entrepreneur and founder of marketing analytics, collaboration and visualization companies like KISSmetrics, Crazy Egg, and his current project, FYI, which is a tool that helps teams search and organize all of their documents in one place. In addition to his operating roles, Hiten is the creator of Quick Sprout marketing blog, The Startup Chat Podcast, and he's an advisor to over 50 startups. Episode TranscriptConnect with:Hiten Shah: Website // LinkedInThe MarTech Podcast: Email // LinkedIn // TwitterBenjamin Shapiro: Website // LinkedIn// Twitter

On the first episode of the Hacker Noon Podcast, hosted by Trent Lapinski, Trent talked to Hiten Shah, a serial entrepreneur known for founding CrazyEgg, and KISSmetricswith Neil Patel. Hiten is currently working on Product Habits, as well as his latest startup FYI.  In this episode Trent and Hiten discuss starting startups, marketing, what it takes to run a business, and Hiten’s favorite life hack. Production and music by Derek Bernard - https://haberdasherband.com/production Host: Trent Lapinski - https://trentlapinski.com  

As the founder of multiple successful SaaS companies, Hiten shares the pitfalls of being too nice as a leader. Every few weeks as part of The Heartbeat, I asks one question to a founder, CEO, or business owner I respect about their biggest leadership lesson learned. This week, I interviewed Amir Salihefendić is the founder and CEO of Doist.… Read the full article

HBR: https://hbr.org/ Product Manager HQ: https://www.productmanagerhq.com/ Product Habits: https://producthabits.com/blog/ Strategyzer: https://blog.strategyzer.com/ The Download: https://www.technologyreview.com/the-download/ NOBL: https://nobl.io/leadership-resources/?category=Newsletter O'Reilly: https://www.oreilly.com/emails/newsletters/index.html Brain Food: https://fs.blog/newsletter/ ProductCraft: https://www.productcraft.com/#subscribe InVision: https://www.invisionapp.com/blog Andrew Chen: http://andrewchen.co/ Single-question feedback form to help us improve PMD: goo.gl/forms/kDEJcBWum9UkE9Rq1 Sponsored by Crema, a 100% US-based digital product agency. Check us out at Crema.us

Today on the Startup Chat, Steli and Hiten talk about what user testing is, why it’s important, and some tips on how to do it right. This comes after a series of blog post Hiten and his business partner have been working on around the topic. After user testing products like Duolingo and Grammarly, Hiten shares what he’s learned from the process, including what works so well for those products and what could be done to improve the overall user experience. Hiten also shares some tips on how you can user test your own products the right way and, if you choose to, test those of your competitors as well. Time Stamped Show Notes: 00:00 About today’s topic. 00:44 Why this topic was chosen for this episode. 02:36 What user testing means. 03:43 Hiten talks about the user test he carried out on Grammarly. 04:19 How much the study cost. 05:10 Why it’s a good idea to user test your competitor's products. 06:08 Lessons Hiten learned from user testing Grammarly. 10:40 Tips to help you user test your products or those of your competitors. 3 Key Points: User testing is the ability to see how people react to an experience. If you're trying to figure out what your users hate about your product, you need to ask them. User testing allows you to understand what’s working and what’s not.   [0:00:00] Steli Efti: Hey everybody, this is Steli Efti.   [0:00:03] Hiten Shah: And this is Hiten Shah. Today on the Start-up Chat, we're gonna talk about a series of blog posts I've been doing with my business partner Marie, around user testing and the value of it. It was a hard one for us to share, and we'll talk about why. Steli, you wanted to talk about it, so I'd love to get your take, as always, because apparently you're reading my crap.   [0:00:26] Steli Efti: Yeah, dude. You're killing it with product habits. Again, for people that are listening. I'm pretty sure that people that listen to the Start-up Chat are already subscribed to Product Habits, but for those that are new that haven't, go to ProductHabits.com and subscribe. I've been on your email list for a long time now, and the content you're sharing right now is the best content you've ever shared, in my opinion. Really it's-   [0:00:51] Hiten Shah: Wow, thank you.   [0:00:52] Steli Efti: It is killer. It is really, really fucking good. The emails that you send are really good. I know that you and Marie, you've kind of gone from a model of considering having a content team that writes these emails, to getting back to the two of you writing these emails, and spending a lot of time back and forth until you get it right. And it really fucking shows. It's unfortunate, but there's no shortcut to excellence and to greatness. You have to put in the work. I love the new format right now, the new thing that you guys do where you do these research studies on other companies, right. On their products, on their user onboarding. You do really deep dives and then you share the deep dives and the learnings that you have with brands that are pretty popular. And are teaching even how they could do things better. So I love that content. It's incredibly insightful. I wanted to pick the last one you did on Grammarly, and share some of the insights you learned there. And then for people that want to learn more, they can just go to ProductHabits.com and read these user research or product research studies in much more depth and detail. But let's talk a little bit about user onboarding and what you've learned through doing these deep dives so far. What are some of the key learnings that you guys took out of it as takeaways?   [0:02:16] Hiten Shah: Yeah, absolutely. A couple things. One, for those of you that don't know what user testing is,

We began this month with a Build episode where we exposed all the aftershocks of using current product management methodologies to estimate user stories. Then in last week’s episode, we dove into Hiten Shah’s new EAT approach which boils down to doing hourly estimates.   Don’t worry if you thought Hiten was crazy, you aren’t alone!   We received a lot of questions, concerns, and objections, so in today’s episode we’re going to dive into the top 3 we heard again and again:   Objection #1: My team is still healing from our previous approach.   “My team adopted agile five years ago and experienced a number of problems that you talked about in the first episode. So, six months ago we took the plunge and decided on no estimates and, of course you can imagine, we're still recovering from it. The wounds are raw. So, how am I going to get my team to try something new especially since this is going to be another investment in terms of time?" — Product Manager from Palo Alto   Objection #2: This won’t for our customers who want quick fixes!   “I hate to play the blame game, but a big source of our problems is our customers. Many want quick fixes, so we end up at their mercy and boy, do they hate eating their vegetables. How do I get them to come around?" — New Product Manager from NYC   Objection #3: My team is eager to adopt a new process but how will this help them follow through?   "Hiten and Poornima, thanks again for this series. Unlike some of your other audience members, I have the opposite problem. My teammates are eager to adopt a new process, but when they hit a snag they are quick to punt and just do whatever they think they need to do to get the job done. What is the one thing you would advise them to have them stick through when implementing the process and practice of hourly estimates?" — Team Lead from Tulsa   Do any of these sound familiar?   Listen to the episode to hear Hiten's response to each! -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.   Check out these additional resources on estimating stories for your product: Product Habits Why It’s Easier For Product Teams To Cram Features & Bugs Into Each Release Instead of Cutting Back Tech Debt: The Cost of Putting “Quick Fixes” Into Our Software Product Product Debt: What Is Product Debt And Why You Need To Prioritize Paying It Down How Long Does It Take To Get A Startup Company Off The Ground How Much Time And Money It’s Going To Take To Productize Your Idea My Nightmares With Engineering Estimates Story Points, T-shirt Sizing and Time Buckets: How Tech Companies Do Engineering Estimates Deadline That Are Doomed From The Beginning No One Likes A Creep   ## Why Hourly Estimates For User Stories And Technical Tasks May Seem Crazy But You Need To Do Them Anyway Transcript   Poornima Vijayashanker:    Hiten, last week we instigated our audience by telling them your EAT approach on how they're going to get rid of their old methods and instead embrace doing hourly estimates. A lot of them have written in with their questions, their concerns, one even said you're totally crazy. I hope you're ready to deal with this pushback and address our audience's concerns.   Hiten Shah:         Yeah, it's not the first time I've been called crazy. It's because I just want everyone to do better. I've heard everything from “there's no way I'm going to be able to get my team to do this, there's no way I can use this approach,” all the way to, “the approach I'm using today, whatever it is, works just fine.” Yet, those same people say they can't ship on time. Also, “we just can't estimate accurately, we've tried it before, and it's impossible.” I've heard everything.   Poornima Vijayashanker:    Awesome. I hope you're ready. Let's just dive right into it.   Hiten Shah:         Let's do it.   Poornima Vijayashanker:  Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech.   Hourly Engineering Estimates Is Crazy                    Over the last couple episodes, we've been talking about estimates, and you'll recall in the last episode we unveiled the EAT method and talked about how this is all about hourly estimates. I'm sure, for those of you out there, you were thinking, "This is crazy, people will never adopt this on my team." In today's episode, we're going to address a number of these concerns. To help us out, I have invited back Hiten Shah who is the founder of multiple products, and his most recent project is called Product Habits.                    Hiten, we put out your EAT approach, your EAT method, and we got a lot of feedback. I want to start by throwing some questions out there from our audience and, hopefully, you'll be able to answer them.   Hiten Shah:         Rock and roll.   Adopting A New Product Management Process Is A Big Investment For A Modern Software Team   Poornima Vijayashanker:    Awesome. Here's the first question, this is from a product manager and they wrote in saying, "Hiten, my team adopted agile five years ago and experienced a number of problems that you talked about in the first episode. So, six months ago we took the plunge and decided on no estimates and, of course you can imagine, we're still recovering from it. The wounds are raw. So, how am I going to get my team to try something new especially since this is going to be another investment in terms of time?" What are your thoughts?   Hiten Shah:         Every time you do a process improvement and it involves product people and engineers, they do like process; if they don't then they're probably working at a really early stage startup and spending a lot of time just probably working 18 hours a day just coding and things like that. That's a whole different story, but in this case it sounds like a larger organization to some extent and a bigger team. In those teams, the best advice I have is don't think it's going to take time. I'm not saying you rush into anything or anything like that, but you can start with the E part of the EAT method and really focus in on understanding how to have your team as engineers and the product team learn to explore and learn to really figure out what the communication differences are between the teams. That technical research outline really helps you do that.                    If you were to implement one piece, start at the top and start with creating that technical outline on the next project you do. This isn't a whole big process improvement, system changes, and take everybody and regroup them, and all this stuff—   Explore: Before You Do Product Estimates Do Your Technical Research   Poornima Vijayashanker:    Call in change management.   Hiten Shah:         Yeah, none of that. No, we don't like that. I don't like that. Anything I suggest wouldn't fall in line with that. Can you just start with starting with the explore aspect of it? Then, playing it out on the next initiative you're going to do, however small or large you think it is? You'll already start seeing improvements.                    Again, seen that happen, heard this objection. Part of it is because of exactly what the person was saying, "I've done this before. It didn't work. The thing we went to is still causing us all these problems, hence why we started with the problems and most of the states people are in." I kept hearing that over and over again. The simple solution is start with this one document and create, what I call, a technical research outline, and use that to communicate with engineers.                    The two main components—again just to repeat this—are the evidence, the reasoning, the customer feedback, anything you have there as to why you're building it so that your engineers and rest of the product team can get close to the customer. My favorite part still is the open questions because you're going to have questions about what you're building that might've never previously been answered in your process. Just that and then having communications while engineering solves this problem, but don't think it's going to take forever.   Customers Want Quick Fixes   Poornima Vijayashanker:    The next question is, "Hiten, I hate to play the blame game, but a big source of our problems is our customers. Many want quick fixes, so we end up at their mercy and boy, do they hate eating their vegetables. How do I get them to come around?"   Hiten Shah:         The good news is you're not asking the customers to eat any vegetable. You want to create that dessert for them, if you want to put it that way, but what you're looking to do is get your team to eat their vegetables. What I would suggest is that you take away this idea that you're ruled by your customers in terms of you have to do what they say and instead start taking a bunch of the items that they're giving you and start going through the whole EAT method process and getting actual estimates because then you'll actually be aligned with them. What they want to see is that you're improving the product based on what their needs are. What you want to do want to do is improve the product based on their needs.   Tell Your Customers What You Can And Can’t Deliver On                    Just by applying the method itself on a high level and starting to go through the process with your team, you can go all the way to the explore aspect and the adjust aspect and you don't have to get to task yet as long as you can have an idea of comparing one thing they want versus another. Then, you can apply the idea that, "Well, we now have an idea that this thing we can do for them is going to take a week, this other thing is going to take a few days," which is probably a process you're not going through right now. Then, you can pick based on that.                    Usually, I pick the thing that's going to happen quickest most of the time just to get all those knocked out and keep customers happy. Over time, you would create a balance of both types of things.   Poornima Vijayashanker:    I'm sensing from this audience person that they probably have some customers that expect things done right away. Maybe like in the next day, week, or month, they have some deadline in their head that they want the team to meet.   You’re Probably Not Delivering A Product Fast Enough For Customer Right Now   Hiten Shah:         This whole process you can add criteria, such as “our goal is to release this by this date,” and then the discussions happen. The whole idea of the process is that you can start setting certain criteria and, to me, what I've done before is put that as an open question. This is the most important thing customers want and we'd like to deliver it within, whatever the criteria is. Then, you get to have the discussions with engineering.                    Here's the funny thing: even though a customer might have demanded it that fast, that doesn't mean today you're delivering it fast enough for them anyway. This is the most common thing. It's like if you have a faulty process or a process that's not delivering it; it's a circular kind of logic. For me, it's being deliberate and actually getting the estimates will help you get to a place where you can deliver something at the speed that your customers want it. Usually, the customers want the communication and they want accuracy just like you want more than they actually care that it's going to be delivered when they want it. If you tell them, "Hey, we can't do it in a day, but we guarantee it'll be done in three," and you get it done in two or you get it done in three they're happy.   How To Get Your Team To Follow Through On Providing Hourly Estimates For User Stories   Poornima Vijayashanker:    Last question for you, "Hiten and Poornima, thanks again for this series. Unlike some of your other audience members, I have the opposite problem. My teammates are eager to adopt a new process, but when they hit a snag they are quick to punt and just do whatever they think they need to do to get the job done. What is the one thing you would advise them to have them stick through when implementing the process and practice of hourly estimates?"   Hiten Shah:         This is great. It's great to have a team that's motivated to try new things. The best thing you can do for a team like that is give them the outlet to communicate at every step about how the process is working because then you can remind them that we're convicted, we need a better process. We're convicted that we want hourly engineering estimates on things, and so we are going to keep doing this process until it works. Thus we're going to include feedback from you, the people who are doing it into the process, and we're going to make improvements over time.                    A technical research outline is created, let's say, and then the engineers work on it, and before you move on to the next step of the EAT method of adjusting, you would take a quick five minutes and let everyone give feedback on the outline itself. Was it effective? Did we miss anything? Are there things that we could've done better? Questions like that.   Collect Feedback From Your Engineering Team                    I think, for me, if you're running a team, your job is to get feedback from them. Even with any kind of process that you want to change or improve, you want to sit there and say, "OK, how can I make sure that the team is aligned on it?" This is what I would call an alignment tool across the board, so that you're getting their inputs as well, and they don't have this fear or this reason to fall back to old practices that screw up the whole process.   Poornima Vijayashanker:    That is the discipline, the getting the feedback and doing the adaptations as you go through.   Hiten Shah:         You can't improve without feedback.   Poornima Vijayashanker:    Yeah, got it. Thank you so much for taking the time to address a number of these concerns and objections that our audience has, Hiten. Any final words for our audience?   Hiten Shah:         Yeah, absolutely. I'm super happy that all of you have watched this. This specific subject was the most controversial subject I've written about, ever in my life. I write about these things on my newsletter, Product Habits, you can sign up at producthabits.com, and I'll be talking more about things like this that are there to help you out all in emails though, no videos, so thank you for having me on video.   Poornima Vijayashanker:    You're welcome. We'll be sure to share the link to Product Habits with our audience.   Hiten Shah:         Thank you.   Poornima Vijayashanker:    That's it for this series and today's episode of *Build*. Be sure to share it with your teammates, your boss, and be sure to subscribe to our YouTube channel to receive the next episode of *Build*. Ciao for now.                    This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.  

I don’t know about you but I HATE kale… That stupid leafy green vegetable with the ANDI score of 1000. It’s really hard to chew, and any time I see it on a menu, I skip it! But I get there are a lot of kale converts who go around saying, “Eat your veggies, especially kale!”   OK, I know what you’re thinking, “What does this have to do with building software products and product estimates?”   Everything.   Just like we have to buckle down and eat our veggies (including kale) to stay healthy, there are a number of things we need to do in order to have accurate estimates that will ensure shipping a product consistently.   In the last episode of Build, we mentioned how a number of the current approach fall short. If you were left wondering what to do next, don’t fret, because in, today’s episode, Hiten Shah is back. He’ll be introducing a new approach to coming up with product estimates, and it’s coincidentally called the EAT method.   As you watch the episode you’ll learn:   How to perform each step of the EAT method — Explore, Adjust, and Task What you CANNOT do with this approach How this approach reduces ambiguity, which is the #1 cause of delays and scope creep OK I know what you’re thinking… “Ugh not another approach!” OR, “This is never gonna fly at my company!”   Well that’s why after you’ve watched the episode, we want you to let us know what your concerns are tweet to us: @poornima @hnshah. We’ll be addressing a number of them in next week’s episode! -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- Check out these additional resources on estimating stories for your product:   Product Habits Why It’s Easier For Product Teams To Cram Features & Bugs Into Each Release Instead of Cutting Back Tech Debt: The Cost of Putting “Quick Fixes” Into Our Software Product Product Debt: What Is Product Debt And Why You Need To Prioritize Paying It Down How Long Does It Take To Get A Startup Company Off The Ground How Much Time And Money It’s Going To Take To Productize Your Idea My Nightmares With Engineering Estimates Story Points, T-shirt Sizing and Time Buckets: How Tech Companies Do Engineering Estimates Deadline That Are Doomed From The Beginning No One Likes A Creep   ## What We Need To Do To Produce An "Accurate" Ship Date For Our Product   Poornima Vijayashanker:        In the last episode of *Build*, we explored a number of approaches to estimating work, and shared some of the shortfalls when it comes to over-, under-, or just not estimating altogether. If you missed the episode, I've included a link to it below. In today's episode, we're going to suggest an altered approach to estimating that you can adopt and adapt for your team, so stay tuned.                     Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayshanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now one of the most elusive processes is coming up with estimates for a project or for a task. You'll remember in the last episode, we shared some of the shortfalls of the current approaches. In today's episode, we're going to suggest an alternate approach that you can adopt and adapt to fit your team and your product's needs.                     To help us out in today's episode, Hiten Shah is back. You'll recall he has built a number of products. His most recent project is called Product Habits. Thanks for joining us again, Hiten.   Hiten Shah:         Happy to be here.   Poornima Vijayashanker:        Yeah, so let's go ahead and dive right in. I know we talked about a number of approaches last time, but I'm curious to hear what's your approach for estimates?   Estimating User Stories Is Like Eating Your Veggies   Hiten Shah:         Well first, I have to say it's like eating your veggies.   Poornima Vijayashanker:        OK.   Hiten Shah:         With veggies, everyone knows they should eat them.   Poornima Vijayashanker:        Right.   Hiten Shah:         Many of us are not very good at eating them. We all know the reasons why. It's for health reasons and to prevent certain diseases and things like that. To me, the idea of getting accurate estimates is exactly like that. Nobody really wants to do it, but everyone knows they need to.   Poornima Vijayashanker:        Well some of us need to buckle down and eat our veggies.   What You CANNOT Do With Hiten Shah’s EAT Method   Hiten Shah:         Yeah, of course, but first let me talk about what you can't do with this approach that I'm going to share because what you can't do sometimes is more important than what you can do.   Poornima Vijayashanker:        Sure.   Hiten Shah:         What typically happens is that you have no estimates, or you have agile with points, or you have some kind of waterfall process, or you have some kind of build, measure, learn, lean startup process going on. If you're not actually doing accurate estimates, you end up running into all these issues. My method will make it so that you don't have to run into these issues. The issues are more issues of what I would call interpersonal communications between team members and teams. They involve things like, believe it or not I've seen this, engineers getting yelled at for not doing their job, so to speak, which would be actually creating the software.                     Another example would be we end up sort of like scapegoating and saying that it's this person's fault, or that person's fault, or this team's fault. You can't do that with your engineers if you take this approach. I think partially most importantly of all, if you're actually able to be deliberate and take the approach I'm going to share, you're just going to make it so that you don't have this lack of clarity across the board. I think that's the most important thing. When there's a level of ambiguity on a team about what's going to happen, when it's going to happen, all that kind of stuff, it leads to all these problems of culture, leadership, management. So you're actually preventing a ton of problems if you can do this method.   Poornima Vijayashanker:        OK, so what's the approach?   EAT (Explore, Adjust, and Task) Method For Providing Hourly Estimates   Hiten Shah:         Yeah, so the approach is called the EAT method. The whole idea behind it is to do this three step process. It's an acronym for each of the three steps. The first step is explore, second step is adjust, and third step is task. The thing is, the whole goal behind it, is to get 100% accurate estimates. That means that you're down to 15 minute blocks, or hourly blocks, of estimates from engineers.   Poornima Vijayashanker:        Wow, so people who normally can't estimate are suddenly going to be able to give you an hourly estimate of how long something is going to take?   Hiten Shah:         Yeah, it's like magic.   Poornima Vijayashanker:        Yeah, it sounds like that.   Hiten Shah:         Like eating your veggies over your lifetime right, and being a healthy person.   Poornima Vijayashanker:        Yeah, I think you're going to have a dive in a little deeper.   Explore: Do Technical Research To Uncover What It’s Going To Take To Build A Software Product   Hiten Shah:         OK, sure. The first step is explore. In that step, there's one sort of piece of that step that's most important. What I named it is technical research. The reason for that is product people are used to doing user research, they're used to doing customer research, and so research is a word that they're used to, and it's something that the nonengineers start. What that involves is creating essentially a technical research outline. There's many different ways you can do it, but a high level of it is you're explaining exactly what you want to build, and you're also including the reasons you want to build it. Majority of time, depending on your organization, the reason you want to build something should be because there's a customer need, customer paying, or a business problem you're trying to solve, or a combination of both. Then from there you're actually going all the way down to if you have mock-ups, if you have any kind of sketches, you're putting it together.                     Then my favorite part of it is when at the bottom you would write this whole idea, or this section, called open questions. These are questions you might have. You can already kind of figure out, you might have already figured out some of the things that might be tough or not tough. Then what you're doing is you're not just keeping that to yourself, you're not just keeping that on your team with your close folks who helped you write it, you're actually providing that to your engineers before they build anything, and before they even think too much about the problem ideally. That's their opportunity to evaluate it. So, that's the first step.   Poornima Vijayashanker:        OK.   Adjust: List Out Open Questions That Need To Be Answered   Hiten Shah:         Then the second step, which is sort of the adjust period, involves after they've taken a look at it, made comments, often times they add their own open questions because they have questions for you too, and so it's just a way to get this communication very deliberate instead of making it all happen in conversations that are either not recorded or just not setup in a way where people can look back at it. From the commenting and the open questions, you're able to adjust what you're going to build. This is the critical piece because if that middle piece of adjusting doesn't happen, that's where estimates completely fall down and that's where you run into all the problems we mentioned earlier in the previous episode about scope creep, and padding. All these things are a result of actually not communicating, and not adjusting what you want to build based on what the engineers tell you is going to be difficult, hard, easy hopefully.                     A lot of times even the most seasoned product person and the most seasoned engineers don't generally have an idea of what's easy or hard, what's going to hypothetically take a long time or not, without actually diving into the details. This gets everyone on the same page about that. After that process, sometimes it takes multiple back and forth to get a really good document that outlines a technical research, ideally anyone on the engineering team that could work on this is able to take that and start tasking it. Actually it's engineering tasks in sort of your task management tool, or whatever the tool engineers are using, Pivotal Tracker for example. Then instead of putting points, that's the time when engineers are able to put in minutes and hours. I like 15-minute chunks is what I've found to be most valuable for my teams as part of this process.   Iterate As You Go Along To Avoid Misconceptions And Miscommunications                     This is one of the things that's more of like what we would call a process improvement. When you do process improvement, it takes iterations to get it right. But what I've noticed is when the teams are deliberate and the product people really bought in to sort of wanting to do better and same with the engineers, this process completely reduces all that ambiguity and misconceptions, and miscommunications that happen when people are just assuming things about what to build and how long things are going to take. By then, the engineers are very comfortable providing very detailed estimate on tasks.   Poornima Vijayashanker:        This is pretty novel, and I know that if I'm hearing this for the first time, I sure as heck am going to be opposed to it because I'm thinking I've got to get my whole team to buy in, there's new things I've got to do, all this technical research. I'm not sure I'm going to adopt this in the next week or even month. I think I'm going to have to slowly unveil it. I think our audience is going to have a lot of concerns for the two of us, but I think we should just stop right here.   Hiten Shah:         Yeah, I have good news. I've heard it all before, so I'd love to hear it from them.   Tell Us Your Concerns Or Objections To EAT Method   Poornima Vijayashanker:        Awesome. Well, Hiten and I now want to know what are your concerns with the EAT approach and doing estimates in this 15-minute interval with overall hourly estimates. Let us know what they are in the comments below. That's it for this week's episode. Be sure to subscribe at our YouTube channel to receive next week's episode, where we're going to dive into these concerns and hopefully address a lot of the objections that you're going to get from your teammates and your boss. Ciao for now.                     This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

What’s probably the MOST popular and frustrating question you’ve come across when building a product: “How long do you think it will take to do task X?”   It’s frustrating on so many levels…   First, we need to produce an “accurate” estimate. If it’s off, there goes our ship date!   Next, we need to give a response that seems “realistic”, i.e. is going to meet the expectations or deadlines set by someone else.   Third, we need to be a fortune teller and anticipate things that come up in the course of completing task X.   Finally, we have to do it the moment we’re asked because we’re expected to know how long any task will take.   I don’t know about you, but despite building and launching a number of software products over the past 14 years, I still struggle with estimating how long a task will take to complete.   There are a number of approaches and methodologies that have sprung up over the years such as Waterfall, Agile and Lean whose goal is to provide a framework that helps engineers, designers, and product managers to estimate how long something will take to build and ship. However, as you’ve probably experienced, each one of these misses the mark.   In today’s episode we’ll dive into the aftershocks you may experience when it comes to following one of these approaches and providing product estimates.   Next week we’ll tackle an alternate approach that may seem too good to be true…   To help us out, I’ve invited Hiten Shah, who is the founder of a number of software products such as Crazy Egg, Kissmetrics, and his most recent project is called Product Habits.   As you listen to the episode you’ll learn the following:   Why we suck at estimating even if we’ve been doing it for a while Why we’re surprised each time our product estimates miss the mark What happens if we decide to “pad” our estimates What happens when we get rid of estimating altogether Why a task we think a task is 80% complete but really it’s more like 50% complete Check out these additional resources on estimating stories for your product: Product Habits Why It’s Easier For Product Teams To Cram Features & Bugs Into Each Release Instead of Cutting Back Tech Debt: The Cost of Putting “Quick Fixes” Into Our Software Product Product Debt: What Is Product Debt And Why You Need To Prioritize Paying It Down How Long Does It Take To Get A Startup Company Off The Ground How Much Time And Money It’s Going To Take To Productize Your Idea My Nightmares With Engineering Estimates Story Points, T-shirt Sizing and Time Buckets: How Tech Companies Do Engineering Estimates Deadline That Are Doomed From The Beginning No One Likes A Creep -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- ## Why It’s Hard to Provide Accurate Product Estimates Under Most Popular Product Management Methodologies Transcript   Poornima Vijayashanker:        Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. One of the most elusive processes has to be estimating how long a project or a task is going to take. And no matter how many times we do it, we somehow just always miss the mark because things come up. Well, in today's episode, we're going to share some of the aftershocks you may experience despite what approach you take when it comes to estimating. In a future episode, we'll dive into an alternate approach in how your team can adopt and adapt it to fit your needs.                     To help us out in this episode, I've invited Hiten Shah, who is a founder of many products. His most recent project is called Product Habits. Thanks for joining us today, Hiten.   Hiten Shah:           Thanks for having me. Happy to be here.   What Happens When We Don’t Accurately Estimate Stories Or Tasks   Poornima Vijayashanker:        Yeah. You and I have been building products for a number of years. We've built a lot of different ones. And I know myself being an engineer and a product owner, no matter how many years I put in, I just constantly miss the mark no matter what. I either end up underestimating or overestimating. Let's dive right in and talk about what are some of the problems that happen when we don't accurately estimate.   Hiten Shah:           Yeah. I think, when we're building products, we don't generally think about how long it's going to take to build them even though we pretend we do. We end up creating a road map with a bunch of timelines and we don't actually talk amongst the team, because, usually, a product can't be built by a single person. If it could have been built by a single person, then you don't have to worry about it as much because that single person has all the answers. One thing that ends up happening is you end up having surprises that come up that you didn't think of. You're thinking about using a certain technology, let's say such as Twilio or SendGrid or an API and the engineer has never used it before. They get in the weeds of it and they realize it's going to take longer than they think. And then your estimate is blown up and you're off. That's a very common problem.   What Causes Scope Creep In Product Management                     There's a few others, too. One other one that I've seen people hit continuously is this idea of scope creep. We're both product people. You happen to be an engineer. I happen to be more a marketer. But we love product and building them and teaching other people how to do it, too. One of the aspects of that is we might still be learning and doing research as the product is being built, and we all of a sudden have this great idea we want to add. We go in and kind of blow up the whole process and expect that the timeline is not going to change or don't even think about the timeline and say, "Hey, we're going to build this new thing on top of the thing we're doing." Or, "Can you add this little tweak?" And not realizing how disruptive that is to the process of building the product itself.   What Happens When Communication On A Modern Software Team Breaks Down                     Another thing that's very common is that if you aren't communicating very well with your team, especially the engineers when you decide that you're going to build something, what ends up happening is the best thing that they can do if you haven't spent enough time communicating early and often is they end up padding. They end up actually adding a whole day—or worse yet—a week or months to a rough estimate. We call it a rough estimate because it's rough.                     Those are some of the more kind of common problems that come up when you're building something and trying to get estimates and actually think you have the right great estimates, which is the most common thing. And then all of a sudden all these things happen that you are probably are not conscious to about what kind of problems they cause in terms of being able to ship something on time.   Poornima Vijayashanker:        Right. I think two other things I'm curious to hear your take on are large tasks. How do you actually divide them up and then the follow through? You think you're 80% way there and then you discover actually you just finished 50%.   What Causes Scope Creep? Large Tasks That Aren’t Broken Down.   Hiten Shah:           Yeah. I see companies creating, even in my own companies, so much work that is not actually broken down enough. You might think that it's easy to add a button somewhere, so you say, "OK. This is a button." You think it's a small task. Maybe you're not the engineer, because often times you're the product person, or even if you are the engineer. Then the engineer, whether you decided to do it as an engineer or the product person, you get into the task and all of a sudden you're like, "I have to add the button." There's all these other things that need to change whether it's the user interface, or you're missing a certain component, or what that button does is more complicated than you thought. What ends up happening is this seemingly small task is actually a large task. It's usually because you haven't thought through all the things that you need to think through when you add something like that. And I'm talking about a button. Imagine a whole feature. Right? And considering that to be a small task when it really turns into a large one. I think the most common thing I see is that these things you consider small are actually large.   What Causes Scope Creep? Thinking That Tasks Are ‘Simple’ Or ‘Small’                     Another common thing is not realizing that what you're asking for is actually a large task. Right. Like adding a messaging feature or things like that. Even a lot of times, I've had emails come in to me from people who are customers saying, "You can send me SMS as notifications. It will take one hour using Twilio, another two hours through your database and you're done."   Poornima Vijayashanker:        Great. Come on down and write it for us.   Hiten Shah:           You want to do it for me? I'll hold you to the three hours, because it's never as long as people say it is.   Poornima Vijayashanker:        Yeah. There's a lot of different approaches we also like to take when it does come to estimating. Even though we know all these problems, we still continue to take an approach. Right? Let's dive into the approaches.   Well-Intentioned Product Methodologies: Waterfall, Agile, and Lean Startup   Hiten Shah:           Yeah. I think one of the most common approaches that is very still operated by in a lot companies is what we call waterfall, which is one task happens after another task, after another task. A lot of times people are waiting on these things. This is actually the reason another process was invented called agile, which I know both of us are familiar with. Where you're essentially—the way I would describe it is you're trying to do things much more efficiently by basically having more regular meetings and having, I guess, smaller batches of work. What ends up happening there is you create this sort of system that works almost on a weekly basis at best. It means that you have a cadence of following up on all the tasks, we call it agile because you're supposed to be more agile with it and it's more nimble than waterfall and that's completely true, but you lose a lot in the process. Those are the two common ways that I'm most familiar with.                     Then there's a third way, which I think is more inspired by things like *Lean Startup*, which again I like to say that we both probably grew up with that so to speak, around us. That's where you are even more hyper—I would call that more hyper agile than anything else, where you're adding in the component of much more customer feedback in the process, because agile wasn't necessarily invented at a time when customer feedback was a popular thing.   Poornima Vijayashanker:        Right. What are some of the painful after effects of using agile?   How To Estimate Stories In Agile   Hiten Shah:           What ends up happening with agile—one of my favorites, and there's a lot of tools out there that facilitate this—is the idea of adding points to an agile process. What you end up doing is you're officiating time. You're saying that something that would take one to three hours is like one point. Or something that would take three to six hours is two points or three points. And they have all these things like Fibonacci sequences. There's a lot of fanciness around points, when you're really trying to understand time not points. The reason that points exist is because—and not that I think this is necessarily bad, it's better than other methods—but some engineers decided that they wanted a metric that wasn't time.   Poornima Vijayashanker:        Right.   Hiten Shah:           They literally said, "It can't be time, because we cannot estimate."   Poornima Vijayashanker:        Because they basically didn't want somebody to know that something was going to take only 15 minutes or five hours.   Hiten Shah:           Exactly. Your minimum there is an hour at best. Often times it's much more. The thing is every team that I've seen implement agile with points in different ways. Their whole buckets around the number of points something takes is all different. What ends up happening is that engineers now feel great because they have a velocity score. And they can talk about how many more points they're doing every week or how many points they're doing every week as a total. And that's really hiding what I would call the truth, which is how long did something actually take.   Poornima Vijayashanker:        Yeah. I know one of the alternatives is to just get rid of estimates all together, but you've probably experienced what that's like. Talk about what results when you get rid of estimates.   What Happens When You Get Rid of Estimating Stories   Hiten Shah:           Sure. If you get tired of agile for whatever reason—and usually this happens because somebody that's a non-engineer is really not into it, because they don't understand what a point is even though it has timings and stuff. Then estimates are completely removed, which means points are removed and then there's just tasks. Then you run into some of the problems from earlier. Is it a small task? Is it a big task ? What it really boils down to...if you have no ability to understand how long something’s going to take or even how many points, let's say, then you end up not knowing how to prioritize what you work on. If there's just 10 tasks and all of a sudden the engineer's working on one and then you ask the engineer, "Oh. How are you doing?" They're like, "Oh, it's going to take another week." Well, if I had known that task you took was going to take another week or two weeks or whatever, I probably would have told you to work on something different because our customers are waiting for things. Right.                     And that tends to be one of the bigger problems that happens, which is this communication breakdown because nothing is estimated, whether it's points or hours or whatever way people want to do it. And you end up having a massive communication issue and then you have these fiefdoms that get created. You have engineering not against, but against product, against sales, against marketing. And everyone's just waiting for product, everyone's just waiting for things to ship so you can make customers happy.   What Happens When You Pad Your Estimates   Poornima Vijayashanker:        Right. One of the alternatives to both these is to create a buffer. Let's pad the system so that as an engineer I don't look bad and as a product person you feel like, oh, OK, there's some wiggle room. But we know that that has its shortfalls. Let's talk about those.   Hiten Shah:           Yeah. Of course. I think padding is probably one of the worst practices, and you might as well have no estimate or no points or anything like that, because you're essentially saying that whatever estimate I give you, I don't know. I don't know. I'm going to pad it. Then you get in this padding mentality and then you still end up with the same problem that you actually didn't have a real estimate, and things are such a moving target that you failed to ship, you failed to actually do proper planning. You end up having a business where you're actually not getting the product you need in your customers’ hands fast enough so you can actually grow the business. I think padding leads to a whole different set of issues, because what ends up happening in the worst way I can say to you—and I've already said it in pretty aggressive ways—is that everyone's lying to everyone else. That doesn't help with prioritization or getting anything done either.   Poornima Vijayashanker:        Well, thank you for taking the time today to share the shortfalls of these three approaches. I can't wait til next time when you unveil your approach for estimates.   Hiten Shah:           Yeah. Can't help but share solutions with problems.   Poornima Vijayashanker:        Thank you.   How Do You Estimate Stories And Tasks?                     Now, Hiten and I want to know, have you tried one of these three approaches and how have they fell short for you? Let us know in the comments below. And that's it for this week's episode. Be sure to subscribe to our YouTube channel to receive the next episode where Hiten is going to dive into his approach for doing estimates. Ciao for now.                     This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

In today’s episode of The Startup Chat, Steli and Hiten talk about Product Prioritization. They highlight how to prioritize what is important for your business and how to get the team on board, working towards the important objectives. Product prioritization is an important metric in the success of your company. You must know what is important for your customer and how your product will deliver that to them. An important part of this, is ensuring the team are engaged in solving the problems and achieving the goals of the company, which allows the product to be optimized effectively. Tune into this week’s episode of The Startup Chat to learn about product development and product prioritization. Hiten, shares his expertise on some fatal mistakes of product development and how to fix those problems. Steli and Hiten also discuss how to empower your team to get involved in all parts of the business. Time Stamped Show Notes: 01:01 Product development questions. 02:20 The number one challenge in product development. 03:41 It’s important to do your research. 04:39 Figure out what the problem in your business is. 04:50 An example of problem solving in business. 05:52 Changing the way you do business to solve your problems. 06:46 Why is product development so difficult. 07:43 Working together toward the main priorities. 08:43 Why removing silos from your company is good for business. 11:01 For more information on Product Development visit Product Habits 3 Key Points: If you can’t figure out your number one problem, you have no business at all. We are used to our own constructs. All teams should work based on the number one priority of the business. Links Recommended - https://producthabits.com [0:00:01] Steli Efti: Hey everybody, this is Steli Efti.   [0:00:03] Hiten Shah: And this is Hiten Shah.   [0:00:04] Steli Efti: Today on the Startup Chat, I forced my man, Hiten Shah, to talk about product prioritization. He's been teaching all of you people how to build better products on producthabits.com. For those of you that are not on the email list yet, pause the podcast right now. Type in the URL on your phone, put in your email address, it's the most valuable email you'll get to learn how to build better products. So, Hiten you published a bunch of stuff on how to do prioritization of products, that's probably why Hiten, why I had to strong arm him to do this episode but I know that some people still need to hear it from you in a different format, so let's quickly bang out an episode on this. People have a product, and MVP, some kind of a version. There is a huge list of ideas they have, of things they want to build. There's a huge list of things that customers tell them to do. There is the potential to look at should we be improving our current features that are not quite perfect? Or should we be building more new features? Should we be building new features until they're perfect and really well polished before we release them, or should we just be like launching new features really quickly even if they're not great? Do we let others tell us what to do? Should we do it internally? What kind of process do we do? Do we vote up features or not? I do think this is a super complicated problem for most teams, deciding how to prioritize, what to build and how to build that. What is your basic framework? What have you learned through all your research? How should companies and teams think about this?   [0:01:34] Hiten Shah: Last year I asked the audience of my email list, right when we were changing the name of it to Product Habit, because it used to be my personal email list and I wanted to do more and help more people, and be very focused. I wanted to do it about product, I really love product and all that kind of stuff.

In this episode of The Growth Hub Podcast we're joined by two superstars of SaaS, Marie Prokopets & Hiten Shah, co-founders of Draftsend & Product Habits, as we hear their views on how to build, launch and market new products in SaaS, including: - The product strategy for Draftsend - The marketing strategy when launching Draftsend + Hiten's key learnings from earlier ventures - How to leverage Product Hunt when launching new products - Hiten and Marie's plans for developing both product & marketing as Draftsend looks to scale up - How you can overcome your fears of public speaking so you can crush it next time you're on stage - What Hiten and Marie have planned for the future and where they go to read and stay up to date on all the latest things in SaaS Marie and Hiten's newest product FYI >> https://usefyi.com/ Draftsend >> https://draftsend.com Product Habits >> https://producthabits.com/ The Artist's Way by Julia Cameron (Marie's Book Pick) >> https://www.amazon.com/Artists-Way-25th-Anniversary-ebook/dp/B006H19H3M/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1521466335&sr=1-1&keywords=the+artists+way The War of Art by Steven Pressfield (Hiten's Book Pick) >> https://www.amazon.com/War-Art-Through-Creative-Battles/dp/1936891026/ref=sr_1_4?s=books&ie=UTF8&qid=1521467307&sr=1-4&keywords=The+War+of+Art "Growth hacking was invented with a mint julep and two beers" >> hitenism.com/growth-hacking Follow Marie on Twitter >> https://twitter.com/marieprokopets Follow Hiten on Twitter >> https://twitter.com/hnshah --- Advance B2B >> www.advanceb2b.com/ Follow The Growth Hub on Twitter >> twitter.com/SaaSGrowthHub Follow Edward on Twitter >> twitter.com/NordicEdward

In today’s episode, Steli and Hiten discuss the importance of arriving at accurate engineering estimates while doing product development. Typically, larger organizations that have a set process tend to be better at giving out estimates than smaller ones. Having experienced, engineering managers take care of this business function leaves the business owners free to handle what they need to—such as sales and/or marketing. Tune-in to learn how to give out accurate estimates and why knowing the value of your dollar will result in quicker, smarter and more cost effective product development. Time Stamped Show Notes: 00:35 – Today’s Startup Chat is about accurately doing engineering estimates for product development 00:44 – Today’s focus is on software, as hardware is another ball game altogether 01:16 – Information on engineering estimates does not exist on the internet 01:26 – Hiten sent out an email to his entire mailing list quizzing them on how they go about doing engineering estimates 01:43 – There is no single way of doing engineering estimates, and some people do not get them at all 01:56 – Subscribe and be a part of the Product Habits mailing list 02:21 – Steli is constantly thinking of ways to better product development 02:37 – Larger organizations seem to be better at product development than smaller ones 03:15 – Analyzing all the responses, Hiten concludes that people who are doing product development the best have a process around it 03:41 – No generic process can be applied to all products; people figure out their own process as they develop their product 04:26 – For all of Hiten’s organizations, a simple process is in place for making engineering estimates 04:50 – It’s critical that engineers on the team understand the value of why estimates are run; cannot do prioritization of initiatives unless you understand how long the process will take 05:26 – Intent is not to hold engineers accountable for the estimate; main reason is to figure out what you can work on and how long it is going to take 06:17 – Waste of resources and rise in hourly costs if there is no estimate 06:53 – Go into the minute details to prepare an accurate estimate 07:28 – Companies like BaseCamp do not prefer to work on projects in excess of 6 weeks since larger projects tend to spiral out of control 07:50 – In early days, product development is generally on track if you are working with experienced engineers and using small, iterative work cycles 08:14 – As your customer base and your team grows, more variables kick in, and product development becomes more difficult 09:33 – Steli’s team is careful to not give out estimates if the project is really complex; break the project into smaller cycles if there are unanswered questions 10:21 – Steli’s team has gotten better at giving estimates, but they still have yet to perfect it 10:40 – Hiten has 3 engineering managers for each of his companies whose main responsibility is to make sure they ship on time—this allows Hiten to concentrate on the product, marketing and sales 11:47 – Sometimes you can be pleasantly surprised as development time will be really quick 12:30 – As companies scale up, there is a cultural shift and people try to better the process 13:00 – Sit down with the engineering team in order to remove objections about providing estimates 13:20 – Once you conduct some high level research and determine the probable future of the product, go to engineering and define a time which will let you determine how fast you can move 13:49 – Create smarter opportunities by bringing engineering into the product development prioritization process 14:58 – In Hiten’s organizations, any task that takes more than a day is torn apart in an attempt to make it quicker