PB 23/06: Six things I've learned from building..
I've been quiet, because I've been building. Here's what I've learned..(spoiler alert #1 = just do it)
Three reasons why I haven’t sent anything out here for a while.
1. Towards the end of last year, I felt I’d said most of what I have to say about developing a product strategy, or how to prioritise, or how to plan your career. I enjoy working with people 1:1 and coaching, but just writing was feeling routine and repetitive. Time to take a break.
2. I felt a little light in hands-on experience around AI, and it became clear was really the only thing anyone wanted to know about. So I knew it was time for me to talk less and do more.
3. Once I started doing, I’ve always found that at any point in time I can either be doing product work, or writing about it. Trying to do both at the same time results in a a horrible dissonance where I can all too often see myself doing exactly the opposite of what I know I should - and what I’d recommend others - to be doing.
Anyway, I’m now at a stage where I’ve been busy building and have something to share. So, first, a quick update on the two products/ projects I’ve been working on. And then, more importantly, six things I’ve learned from the process.
Product Vitals
For some months now I’ve been working with the fabulous Tom Morgan to build ProductVitals. Our idea was, and still is, that 360 Feedback is an essential tool for developing product teams, but all too often the tools that people have to do it with where they work, simply aren’t up to the job.
So we decided to build something.
Actually, when we first met, we very much decided not to build something - but one thing led to another; and both our confidence and LLM capabilities improved, and we now have fully hosted software that will takes the results of a feedback survey and creates awesome personalised reports.
I’ve posted about it here…and will talk about that a bit more another time - today, I’ll just focus on building. See the end of this for a bit on ‘how we did it’
What The Podcasts Say
You can find this at https://www.whatthepods.co.uk. This is an aggregator of UK political podcasts, and a personal project/ obsession on a number of levels: both in terms of the growth of podcasts as a forum for political discussion and insight; and the technical challenge of transcribing, summarising and (the difficult bit) then organising the content into something meaningful without hiring an army of editors.
I’m going to keep this going till September (think there’s going to be enough stuff going on till then). And then I’ll take stock. But if you’re interested in UK politics. Take a look, sign up for the email and let me know what you think.
6.things I’ve learned
1. Get building. You only really learn by doing.
I’ve probably learned more about software development and product management in the last few months than I learned in the last decade. You could say that just exposes a load of my knowledge gaps, and makes you wonder how I ever got away with a number of quite senior product jobs - and you’d be right.
But whatever job you do now, and whatever job you want to do, and in fact however old you are: you will only be more effective if you understand some of the fundamentals of how software works. And even though AI can take away the effort of writing actual code, it really makes you think about functionality, user experience, prioritisation and a whole host of other things, from the most fundamental level.
2. How you really learn: Build → Use → Iterate
LinkedIn and other places are full of people saying they’ve built X or Y in 60 seconds. And TaDa!
The truth is you don’t learn anything by just putting a single prompt (or even a great big long PRD) into a coding engine, whether it’s Lovable, Replit, ClaudeCode or Copilot or Codex.
You only start learning when you build -> use -> iterate. When you realise that that decision you made yesterday has now stopped you doing the thing you want to do today. When, in other words, you become a real owner and architect of some software over a sustained period of time.
3. Start simple, but don’t stop there
I think the first thing I did was a simple to-do list in Replit. Which got me up and running, but really this was just a bit of javascript running locally. My next thing was a more ambitious to-do list (ok, like any good procrastinator, I’d much rather develop a to do list rather than actually doing stuff)- but now with an actual back end, with authentication, and hosted so I could access on any device.
ProductVitals and WTPS are both full blown hosted apps - as they should be. But they weren’t born that way. A couple of months ago, I/ we just wouldn’t have known hot to get there - we had to learn our way there.
I’ve been really surprised about is just how far you can go if you think carefully. Both products are way, way, way more ambitious than I / we imagined.
Oh, and this is why i prefer ‘building’ to ‘vibe coding’ - because once you get going you really are building - not just using an agent to write some code for you.
4. Get to know a stack - and stick to it
As you start to work with apps that are hosted, have a database back end, have some kind of authentication, it helps if you’re using the same tools over and over again.
By a process of trial and error, I’ve ended up using Claude Code + GitHub + Supabase for hosting the Postgres dB (and handling authentication), Railway for hosting, Resend for sending out emails. I’m sure there are other solutions out there, but this works for me. I know where everything is.
The next step for me is the right tooling for developing a downloadable MacOS and/or iOS app.
5: It’ll cost but a) it’s an investment in yourself and b) you can optimise later
The less expert you are, the more you’re going to spend on LLMs, and a host of other goodies. It’s not cheap. I’ve ended up on the £70 a month Claude Code option. Lots of other tools are cheap/ free as my usage levels are pretty low.
There’s a cost to every podcast I transcribe and summarise on WTPS - but in the background I’ve been busy making sure that a)I’m using the cheapest model to do the work and b) I continuously check for double processing (I found I was initially doing twice as much as I need to)
Still this is worth it. The cost is a fraction of putting yourself on some Maven course and the learning is potent. But, do see optimising - both for the sake of software health and cost - as part of building, which takes me to..
6.Be proactive about tech debt: Get [Claude] to step back and act like a software architect every few days.
I’m sure there’s a way to automate this, but I just do it manually. Particularly after a flurry of feature development I have to stop and say (something along the lines of) ‘Can you act like a challenging sofware architect and review the overall health of my codebase. Please look out for redundant or duplicated functionality, any security risks, or other issues that need to be resolved for the long term health of this produce’.
Do I understand everything it comes back with? No - but the point is unless you ask your coding agent to do something like this, the debt just builds up.
Building ProductVitals …
When we started on ProductVitals, Tom and I built up individual bits of a workflow separately. I developed a data structure and a set of scripts in AirTable that took raw survey data and using a number of different (AI generated) scripts to spit out a Markdown file report that was all data. Tom then had a separate engine that took that markdown and created 20 pages of graphics and text that could be edited.
We had to iterate on this a ton, and it was only when we had everything just right - we felt confident enough to then bring it all together into a single hosted application (and in doing so removing a lot of manual processes).
We’re anything but done yet - and now planning a ton of optimisations to both make it easier for us; and more attractive for potential customers. [example: We still use a third party for a questionnaire - because that is very much commodity functionality, but now we know what we want, that will change soon.]
If you’ve got experiences to share about this, or need any help to get you started (or get out of a rut)…don’t hesitate to get in touch!