Andy Smith

🧡 Would you like to help your team fix their product and UX pains? Between now and 15th July I'm looking for 2 tech focused start-ups to help get their product and UX pains fixed. Just FYI, we recently helped one start-up refocus their team around an undervalued existing product, that they didn’t realise clients were actually clamouring to buy. If this sounds like you, drop me a Direct Message. #product #ux #startups

21

This is something I really want to celebrate! Both the outcome with a seriously improved, modern and great looking new app, as well as the people who made it happen! It’s been a truly massive undertaking during which many teams and individuals have been put to the test. I’m immensely proud of our teams and how everyone has stepped up and delivered time and time again during this journey. I have two main takeaways from this project: 1. Always strive to make sure everyone involved understands the why. Deep understanding of the desired result from a particular change enables many more brain cells to think through the implications, potential problems and opportunities. Even the most brilliant minds will have trouble understanding every aspect, implication, or even opportunity stemming from a change or introduction of something new. 2. Technical architecture needs to be an integral part of the change process in any project of this size. I firmly believe that we would not have succeeded in delivering a successful outcome at the speed at which this was delivered without a very well thought out technical architecture that support such a high pace of change while still also supporting consistency and stability across the experience. To everyone involved in this project: Thank you! I feel privileged to be working with so many brilliant minds.

40

2 Comments

2024 is nearly over. Did you already invest in yourself? Maybe you still have budget left for your personal development? If you want to build up your skills on product development, I have two great recommendations for you - both for product, design, and engineering people: 1️⃣ November 6+7 the Tech Leadership Summit will take place in Zurich, co-located with the renowned Product Management Festival. One ticket buys you access to both! My discount code "DiscountSpeakerTLS" will cut the price by 20% - but the value stays at 120%! 2️⃣ November 13+14 will see the Digitale Leute Summit in Cologne. You can learn from amazing talks, but also join full day content-packed workshops. My discount code "DLS24JAN20" will give you 20% off of tickets. Spoiler alert: 2025 will also bring its challenges. 😉 Set yourself up for success! The direct links are in the comments. Disclaimer: Okay, okay - I will also give talks at both, but you can easily go to the other talks instead. 😘

57

6 Comments

Should you rebuild something from scratch or fix the current solution? The choice isn't obvious, and both approaches have pros/cons. Unfortunately, I think too often Individual Contributors (ICs) want to do the former. I understand - building new is fun and exciting. But it usually comes with a huge cost: time to develop, test, adopt, migrate, scale, etc. Also, guess what… your new solution won't be perfect and will need fixes and maintenance, just like the thing being replaced. So, make a conscious decision. Look at both options and think about the business first. #dataengineering #dataarchitecture

36

11 Comments

Product management is never one-size-fits-all—and that’s exactly what we discussed on the Scandinavian Product podcast. Afonso Malo Franco and I examined how the role changes across startup, scale-up, and large enterprise contexts, and the impact industry nuances have on decisions. Happy to share my experiences at Ardoq, Kahoot!, and Google. If you’re a PM looking to broaden your perspective on how to build and grow products in diverse settings, this conversation is for you. Check out the full episode here: https://lnkd.in/gecSm3HP Hope you enjoy! 🎉

53

1 Comment

We've had an EM role open on our team for several months. This is a post about everything we learned from why we haven't filled it yet. I'd love to get your help in filling it! 🤝 The role: - EM for our 0-to-1 team within Postman, with the goal of defining and winning our category for a new kind of API-level monitoring/observability tool. Our team came into Postman through an acquisition and we're now building the Postman version of our product, using the same tech. - Help scale our product and team from alpha into beta. We are a department with six engineers and approved headcount to grow a lot more in the next year. - The role is 60% prioritization/roadmap management, 40% building the team. The current team members are high-ownership, independent, founding engineer types. 🤔 Misconceptions, miscalibrations, and lessons: - Initially, the role was called "Senior Engineering Manager, Observability." Instead of getting the product engineering managers we were looking for, we primarily got interest from platform/infra EMs. We got thousands of inbound applications and spent months zeroing that out. 🙀 - Previously, our recruiters were sourcing a lot of folks with observability backgrounds. We've learned that since we're actually building a new kind of observability product, much more focused on UX, the profile we're looking for is product-focused rather than tech-focused. No observability experience required. - When people think Postman, they often think of our core product: the API client. So we were getting more interest from folks looking to scale a product, rather than 0-to-1 "I want to build a team and product" types. Postman actually has several other products, for instance testing and Flows, our no-code tool. There is a lot of interesting 0-to-1 work on our way to growing as a multi-product platform! - Some people have the perception that Postman isn't one of the high-growth companies because they're not seeing lots of their friends joining Postman. Postman has quadrupled since 2020, BUT a lot of the engineering growth has been in India. (Postman is the biggest SaaS company to come out of India!) Our team is part of a recent change to grow our US engineering presence. Many of us leaders across the company are looking for folks to join early cohorts of US-based product engineering and platform teams. 💡 What we've changed on our end: - We've deemphasized the "observability" part of the job and emphasized the "new product" and "product engineering" parts of the job. - We've also switched our own reachouts to look for people with product engineering experience at SaaS companies with product-led growth. 👩‍🚀 Help us find our EM! We now have a solid pipeline, but haven't yet made a hire. We'd love to hear from you if: - You have thoughts about how to improve our EM search. - You know someone we should meet. - You're a scrappy EM looking for an opportunity to build a new product while growing a team. Look forward to hearing from you!

68

8 Comments

We're looking for a senior-staff PM now at Honeycomb, who will drive and own a multi-year vision for a net-new, permanent and significant expansion of Honeycomb's product surface area: https://lnkd.in/g2sM_TfC I’ve sat in this role for 3.5 years now, on and off, so you’ll be inheriting a lot of my regretful decisions. But I’m here to help you navigate that! It involves big data (for real), deep OSS involvement, lots of customers who love the product, and a great team to boot. If you like the idea of thinking through how you’ll turn 10M events per second into 100k, without breaking the bank, and making it as semi-automatic as possible, without losing signal on that data, and building a compelling UI that lets people build and monitor this stuff, this might be up your alley! Wanna talk with tons of customers and spicy sales engineers who have to sometimes commit code crimes to make stuff work, and then tell you about it? Wanna make painful prioritization decisions? Wanna find a way to execute on a multi-year vision and not get lost along the way? Click the link above. Wanna eat shit in front of a customer whose exact set of constraints violates every tradeoff decision you made? And then go back to them 4 months later with the good news that you’ve fixed it all? Come say hi! Wanna try to wrap your head around someone's perceived notions of how observability works, and find creative ways to reorient their worldview? Hi hello please apply. Wanna get deeply involved in the #opentelemetry community, become a core contributor, attend lots of community events, and be continuously infused with customer problems and feedback and also overall industry directions? You know what to do. Wanna work with a very product-minded engineering team who will push you to get stuff done? Wanna be a part of a group that is usually fast, usually right on the first go of things, and isn't afraid to try things and maybe pull them back if they're not working? Wanna have fun too? Clicky clicky.

59

4 Comments

#productwalk <start> <storytime> I’m not the greatest storyteller. For real, if I’m crafting a narrative it takes time, significant thought energy, core data, and deep understanding of what I’m talking about. But that’s ok. Why? Because as a product leader - as a leader in general - it’s not about the ability to just tell a story that is critical, it’s about the passion you have for what you’re talking about. <passion> When I am most excited about something with my job, it’s because I see the #value that it will add for the #users. That sets a fire under me not just to move mountains to deliver it quickly, but also to transfer that passion to the team. Putting the #userfirst is at the core of delivering great products, driving a mindset that shifts from just getting a thing done to delivering a GREAT outcome. <profession> Long have there been debates about profession vs job. Indulge me for a second about these two words. Profession is rooted in a formalization of a skill set, something that required training, qualification, experience to be a part of. Something that was more than just a task. A job, however, is focused on a task, a thing that you must do, more narrow. This is the reason why when we do #productvalidation we run through a #jobstobedone (#JTBD) analysis so we can understand the full scope of what the user needs. When you approach your role as a #productleader as a professional vs a job, your mindset shifts from a myopic view to one that is scanning the horizon to ensure that the thing you are delivering, the problem you are solving, addresses the problems the user has with orchestrated unity and harmonization. <action> So what does this all boil down to and why bring any of this up? If you are in #productmanagement you’re a product professional. If you’re in #engineering, you’re a product professional. If you are in #marketing, you’re a product professional. If you are in #qualityassurance, you are a product professional. If you are in #sales, you are a product professional. If you’re the #CEO or #founder of a company, you are a product professional. Picking up a theme yet? As a product professional, you are part of a team that drives quality focused on delivering products that a user can employ to get their jobs done. You are part of a #team - and as a Product Manager you help drive that team to that goal, fueled with passion for what you’re solving, with the user at the heart of everything you say and do. <lets.walk>

7

1 Comment

I have spoken way too much about wanting to build a learning plattform over the years...but I finally actually did it! It was a ton of work, mainly because it took me many attempts to figure out a unique learning method, that might add something to all the amazing learning resources that are already out there. If you are curious and maybe want to brush up on your Tailwind CSS skills, give it a try at https://uibasics.dev. The first two levels are free. And if you like it, consider giving me an upvote on Product Hunt so others might find it there as well: https://lnkd.in/e6QPS7Be

50

8 Comments

Daily Stand-Up Meetings: Just for techies? I’ve been leading software development teams for over 20 years, and daily stand-up meetings have been a core part of my routine for at least 15 of those years. You know the drill: - What did you do yesterday? - What are you doing today? - What’s blocking you? For me, stand-ups are so ingrained in the way my teams operate that I can’t imagine working without them. They help us stay aligned, identify roadblocks early and build team spirit. But here’s the thing: in companies I’ve worked with, I’ve noticed that teams outside of software development—rarely adopt stand-ups. Why is that? Have they tried and found they don’t work? Do they see them as unnecessary? Or do they simply not know how impactful these quick check-ins can be? I’m curious — Non-techies what’s your experience? If you do stand-ups: How have they helped your team? If you don’t: Have you tried them and decided against them? Why?

19

14 Comments

🚀 Check Out Our Latest Blog Post! Lisa Hagen and I have just shared a new blog post where we talk about the journey and inspiration behind Ready Steady Grow. If you're interested in learning more about why we wrote the book and what it's all about, head over to the blog now! 👉 Read the blog here:

1

1 Comment

📝 It’s the first week of the second half of the year. Engineering managers, here’s a few things that are worth doing. ⬅️ Review last quarter (Q2) Sit down with focus time and look back. Go through your team and project retrospectives and check against your mental understanding of how the team did and felt. Try to capture 2-3 aspects of the quarter that you think were absolute gold for the team and 2-3 that were misses. I find that the act of writing these down will help me understand the facts - do I have surface level understanding or do I know exactly how the team worked? At incident.io we have a way to channel customer feedback about what the team builds so I don't capture it again but if you don't have this I'd recommend sending over a few nice things customers have said about what your team has shipped. 📝 Recap first half of the year (H1) Most good managers tend to know how the team has done. It is worth digging a bit deeper and write things down. Did the team trend upwards or downwards? Even if a team has done well, the direction of travel might be wrong. One thing I love to do as I reflect on the first half of the year is to write down what I would have changed and done differently. And here’s the kicker: I then ask myself if some of them are still in time to be done - and sometimes they are but easily forgotten if you don't reflect. Especially changes to processes that get in the way. ➡️ Look forward (H2) 1. Start with something simple: are your people well rested? Do people still have 20 days to take or just 5? Useful time to nudge people. 2. What is the behaviour you want to change in yourself (and perhaps in the team)? No one is perfect and everyone makes mistakes - but without change (even if minimal) you end up being behind what you could be. 3. Have your stakeholders changed with any company change in goals? If so, meet them, align yourself and your team with them. 4. Is your team going to do work that introduce risks to the company? If so, write them up, raise them with you manager, and start work on reducing them. 5. It’s easy to overthink and plan for an entire half year - I’d recommend not doing that - keep it simple, nail the quarter (Q3) but make sure the direction of the team is right. 💬 Ask people for feedback You’re always thinking of all of the things. Usually not thinking about yourself. How well have you done? Do you know your blind spots? Do you have your top 3/bottom 3 for you to work on? Have you reflected on your work and how you drove the right outcomes for the organization? And finally, have you taken enough vacation? If not, why not? If the answer is “only I can do X”, you need to train and delegate. Rest is important - it grounds you, builds you up, and re-energises you.

19

7 Comments

What connects product management and the rise of the far right? Chatting to a talented UX friend recently about her psychology degree - and how valuable it is in her professional work - set me thinking about an imbalance I see in the product world.   We talked about how people get stuck in extreme opinion bubbles, not knowing reality from fantasy, lacking historical context, and how that can so easily be abused. And I hear a lot about a degradation in funding - and I suppose social respect - for the study of subjects that aren’t hard technical or business disciplines. It struck me that Product belongs to the Humanities. The respect for evidence, the independence of thought, the hard questions about human behaviour and value. And just as society as a whole seems skewed away from parts of its own toolkit for understanding, product feels skewed away from a crucial part of its own foundations. The focus on people. I mean the focus on people both in terms of understanding users and markets, and for empowering and inspiring teams. At least, that's how it looks based on a lot of what I read and hear within the profession, which often seems technology obsessed rather than starting from people or even business. Of course, I’m exaggerating. I’m suggesting a course correction, not a pivot. I want us to employ the full spectrum of what product should be as a discipline. It’s not that tools, technologies and intricate techniques aren’t important. But product needs a little course correction back towards people and humanity. Especially given its fundamental role in making sense of AI. 

36

🚀 New blog post 🚀 This week’s discovery: 🦥 Good work can look lazy 🔨 Building on what you already have 👫 Emotional differences in modern dating 🔑 The only metric that matters Read the full post: https://lnkd.in/eT-S5KFx #ModernWork #SelfAcceptance #Relationships #PersonalSuccess #PursuitCommunity

5

I need some volunteers for an experiment. It involves AI, so it must be cool. A common challenge I see when working with product development teams is balancing user story discussion/collaboration with needed epic/story documentation. We all know good stuff happens when we get our cross-functional teammates around the [virtual] table and hash things out. But, the results still need to be captured. Ugh. I know you tried just attaching a picture of the whiteboard. Me too. It doesn’t work in most contexts. Writing it up feels like double work, and the all-too-common result is that people fall back on writing the Jira ticket and skipping the conversation. It’s burned into my head: Alistair Cockburn emphatically stating that “a user story is a promise for a conversation” and Jeff Patton hammering home that “shared documents aren’t shared understanding.” Enter the experiment. AI meeting summary technology is in a decent place. What if we had the conversation, let the good stuff happen, and the AI handled most of the documentation? Has anyone tried having an AI summarize their user story conversations? Who’s willing to give it a try? Admittedly, the engine may require some tuning, given the specialized use case—just a thought. #productmanagement #userstories #AI

7

9 Comments

The secrets of how experienced engineering leaders accelerating growth of new Tech Leads... 𝘔𝘪𝘯𝘥𝘴𝘦𝘵 + 𝘗𝘦𝘳𝘧𝘰𝘳𝘮𝘢𝘯𝘤𝘦 𝘦𝘹𝘱𝘦𝘤𝘵𝘢𝘵𝘪𝘰𝘯𝘴 + 𝘚𝘶𝘱𝘱𝘰𝘳𝘵 + 𝘍𝘦𝘦𝘥𝘣𝘢𝘤𝘬 = 𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗠𝗶𝗻𝗱𝘀𝗲𝘁 Individual focus → 𝗧𝗲𝗮𝗺 𝗳𝗼𝗰𝘂𝘀 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗘𝘅𝗽𝗲𝗰𝘁𝗮𝘁𝗶𝗼𝗻𝘀 I love Andy Grove's definition 𝘓𝘦𝘢𝘥𝘦𝘳𝘴 𝘢𝘳𝘦 𝘫𝘶𝘥𝘨𝘦𝘥 𝘰𝘯 𝘵𝘩𝘦 𝘰𝘶𝘵𝘱𝘶𝘵𝘴 𝘰𝘧 𝘵𝘩𝘦𝘪𝘳 𝘵𝘦𝘢𝘮𝘴 𝘢𝘯𝘥 𝘵𝘦𝘢𝘮𝘴 𝘵𝘩𝘦𝘺 𝘪𝘯𝘧𝘭𝘶𝘦𝘯𝘤𝘦. Although I prefer to use the term 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀. It's possible for a team to product a lot of output but not much value! 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮 𝗧𝗲𝗰𝗵 𝗟𝗲𝗮𝗱? A team scoped Tech Lead can have many flavours. Is team leadership included? What about line management? What about delivery? Clarity is key 𝗦𝘂𝗽𝗽𝗼𝗿𝘁 Engineer → Tech Lead is a tricky transition. Holding more frequent 1:1's initially Seek feedback from team Stay close 𝗙𝗲𝗲𝗱𝗯𝗮𝗰𝗸 We all make mistakes when taking on new responsibilities  Provide both reenforcing and corrective feedback Observations + Impact = Actionable feedback Learn from mistakes Celebrate the wins P.S How do you support new Tech Leads?

9

4 Comments

Currently playing with bolt.new but it’s turned into a full on development session! I had the idea to create a product for product management organisations to solve the problem of ‘asset discovery’ i.e. when you have loads of teams who all have their docs in different places, it can be useful to have a simple entry point into all their docs. I first started out in ChatGPT, talking to it on my drive home last night to build the product spec and a business plan. I fed the output into bolt and it failed because it tried to build the whole app in one go. I then transitioned to building the app in small increments and oh boy, is it amazing! Checkout this little snippet I just recorded - if you’ve not played with these tools yet, this’ll give you a good idea of what’s possible… let me know your thoughts and if you have any questions.

15

3 Comments

A little story. Recently we've got a small customer request from an internal stakeholder team for expanding a service with a new functionality. Our dedicated architect spent a whole week to prepare a bunch of arguments why this task will require a total reconstruction of existing platform. But the truth is that development team already made that change in 2 days, and the customers were in tears of happiness closing important deal. It's the one side of the medal. But also I know teams who believing in strength of Agile, uselessly wasted time, budget and resources. Just because they initially incorrectly designed the system, not taking into account existing constraints and limitations. There is no a silver bullet. However, there are experience, best practices and common sense. I've chosen "Continuous Architecture in Practice" to expand my knowledge in Architecture topics, but this book is mostly about general Agile principles in architecture and non functional requirements. The entire book can be shortened to six principles (other parts are wordy explanations of these obvious postulates): - Principle 1: Architect products; evolve from projects to products. - Principle 2: Focus on quality attributes, not on functional requirements. - Principle 3: Delay design decisions until they are absolutely necessary. - Principle 4: Architect for change - leverage the “power of small.” - Principle 5: Architect for build, test, deploy, and operate. - Principle 6: Model the organization of your teams after the design of the system you are working on. If you have free time, take a look at this book. It wouldn't hurt. ★★★☆☆

2