S3E1: Teaching Product Through Real World Experiences: A Conversation with Adil Hussain

On today's episode, we'll be talking to Adil Hussain, a product manager for the Financial Times,
who works to help aspiring product managers get started in the field. Adil's going to tell us
how he got into product management and how that led him to want to help others. Adil's also spent
time in both the public and private sectors, and so we'll discuss how product management practices
differ between the two. We'll also talk about the UK's GDS, or Government Digital Service,
and how that can be useful to product managers all over the world. Adil, it's great to have you on
Productly Speaking. Hey Karl, thank you so much for having me. It's a pleasure.
Glad to have you here. Tell us about how you got started in product management.
So I accidentally founded a bit of a startup when I was around 14, kind of school age,
quite a lot of web development, marketing with my co-founder. We're just doing a lot of what you
would call, I would say, product management now in today's time, but we were just doing a lot of
analysis, requirement gathering, you know, speaking to our users, trying to understand what they need
and how, kind of playing the founder, the CEO role, you know, all of that all together at once.
That's kind of where I got into a little bit of a product role, but didn't know it was product at
the time. Initially, we were doing a lot of that, you know, the whole kind of building the gap
between technology, business, user needs, et cetera. Fast forward, like many, many years
later, that was kind of a couple of years, did that during school and study time. I then started
working for a SaaS tech company about seven or eight years ago. And there, that's where I discovered,
like, you know, how software teams are run, what product management kind of is, just heard of the
title, worked quite closely with support team, sales team, account managers. So that was fun. That's
where I first came across product. We had a product manager who was amazing. It turned out to be one
of my first mentors. And I'll kind of go into that into a bit more detail, but kind of just looking
at how product was done. It's when the penny dropped and I thought, oh wait, I've kind of done
some of this before. So that was quite interesting. It's like, wait a minute, like I've had these kind
of discussions, you know, balancing a lot of these different needs and different elements to building
good products. Even though I wasn't actually building a SaaS product, it was more of a methodology and a
mindset. That's kind of where my first exposure to product came from.
Going back to that time period when you were 14 and talk about how you get into doing your own
startup and you've got a co-founder and all of this. I can only imagine that this looks like you had
found a problem that you saw a solution for and you're like, I could do that. And you've got a friend
with you who says, yeah, let's do this. And then you go and you do that. And because you've already seen
this problem and you know the problem well, and you're like, yeah, if we did this to solve it,
you just are going. You don't even really think about the fact that you're doing product or anything
like that. And it's kind of interesting that, you know, product management is this discipline where
it really is about figuring out how things work and getting into the nitty gritty details and
tinkering. And once you have that type of love, it just goes from there.
So tell me a little bit about that and how that really was kind of your first introduction to
product, because it's not something you think about as product when you're in the middle of it.
Absolutely. No, you put it really well. I think even now I come across people that I mentor,
that I teach or just have normal conversations with who aspire to break into product and who've
maybe founded their own businesses, their own startups, don't realize that they're doing a lot
of product style thinking. For me, especially when I first kind of went into the world of tech,
per se, it was about understanding user needs and building products, building sort of marketing
campaigns, websites, whatever it was, according to what our client or user required. For me,
it's one of the themes that you'll probably see across our chat. Product management for me is
about solving those problems in the right way and also making sure that we're building really good
user experiences. And that's been the key theme for me throughout my career as well, and especially
my foundations and kind of where I come from as I started my career in product. So it's always
crucial. And I think, especially if you are a founder or, you know, you have your own business
or your own startup, identifying kind of the problems that your users have or your clients
have and solving those, it's crucial to business as well. So it kind of forces you to think in that
mindset of, okay, this is what my client needs or requires. This is where I can kind of pivot and,
you know, suggest something different or make sure that we're providing the outcome that they're
looking for. So they're happy and they go away with a satisfactory service. And essentially that's
kind of how it scales up. And that's what we do in product day to day, right? As part of the wider
job and the wider role, although not to simplify it too much. I think that's one of the most crucial
parts is always having a user at the heart of what you're doing.
So you got into roles that were actually called product and now you're like, okay, this is what
product is. Kind of tell me about the rest of your journey from that point forward.
As I mentioned, I started off at a software company, a little more formal exposure to
how technology teams, software building works. And one day in one of my one-to-ones with my
manager, my manager asked, where do you want to go? What do you want to be? And I instantly
just said, product management. Didn't really know what the job entailed in sort of a professional
setting. You know, it's only now retrospectively that I'm telling you when I think back towards
my younger school years and what that meant. But yeah, I just said, oh, I want to do product
management. And my manager was an amazing guy, still in touch with him. Said, okay,
let's go and chat to our product manager on the team. And this was pre-COVID. So everybody
was in the office, you know, everybody was kind of collaborating, communicating together
in the same space. So the three of us got into a room, really tiny sort of, you know, three
people room. And we just spoke for 20 minutes. And my PM at the time just kind of mapped out
everything. This is what product manager does. This is what the day-to-day entails. What do you
think? Can you deal with this? And I just sat there like me, just like, yes, maybe.
And I think that's leaving that room is where I thought, yes, this is exactly what I want
to do. And that's when a lot of those pieces in my mind of the puzzle kind of started connecting.
And then just observing day-to-day, like what the PMs, POs were doing on our teams really
helped me understand and cement that this is where I want to be in terms of my career.
There's a second sort of part to this as well, in terms of my role at that company was
more around customer support. Sort of a consultant slash customer support. So I was always at the
front end kind of speaking to our users who are using our SaaS products and understanding,
you know, what their problems are, solving their problems, you know, all the way from
changing passwords to writing custom SQL queries. And there were so many occasions where I would pick
up a call and we'd had our regulars and they were amazing and really nice users who would have
these ideas and, you know, enhancement requests and features and all of these things. But in my mind,
I would put together this roadmap. If this product was mine at the time, I wouldn't say PM, but this
is what I would do. This is how I would do it. And this is how we would maybe, you know, help this
person uncover that problem. So I think that's where my journey kind of started and where I started
actively looking for a product role to kind of go into and test the waters with.
Yeah, that's very cool. I mean, I also come from a customer support background before getting into
product management. It really does give you a perspective on customer needs and how customers use a product
and just understanding that there's a hundred ways to use a product, not just the one or two ways that
you have in your product features deck where you tell people all about your product.
Absolutely. A hundred percent. I agree with that. There's just so many different types of users that
we have to consider and balancing a lot of those, making those priority calls in terms of what's next
for the product, but what will also be beneficial to our users. And I think even now in today's day and
age, when there's so many alternatives to your product and competitors in the market, it's about
how do you stand out and how do you also meet those needs to make sure that you're an exemplar product.
And then there's the times where you get a request that you just have to say no to because that's not
the direction that you want to go.
That's it. Sometimes easier said than done. And also depending on where you are in the business.
Like for me, when I was working in customer support, it was so easy. It was like, yeah, we'll make a note of
that and then it will go into the backlog and never be seen again. And then a year down the line,
somebody will call up, oh, remember that thing that I requested a year ago? Like, where is it?
But now when you're in that driving seat, it's a lot more difficult to do.
Well, the more customers you get, the bigger your backlog becomes and the more that becomes a thing.
Because at some point you're looking at, we've got 300 feature requests and we can't do 300 feature
requests. So we've got to prioritize. And unfortunately, you know, the 10 that we picked to do over the next
year, they're going to be happy about it. But the other 290 are going to be like, why is my thing
not getting worked on?
Exactly. And I think it's also important that we are mindful about how we share or how you break
that news about saying no. From my experience, it's like some users are less vocal than others.
Some are more understanding, others maybe not. Some may require a little bit more convincing.
Generally, you know, being able to tell good stories as a product manager and being able to tell a
narrative and kind of explain where you're getting to in simple terms, as we all know, it's very,
very important.
Yeah, that storytelling is something that I like to talk about and think about, because
ultimately, if you can tell a good story and you can communicate that this is the story we've got
and make that really well with the customers and future users, etc., you're going to see a lot of
pickup. That message is going to land a lot better than if it's just no real story or the story's bad.
Yeah. Yeah. Being able to tell more of a story about why this is not going to be done. You know,
what is your why? What is your purpose? Why is this not a good fit for this product right now at
this product's lifecycle? And hence why we're not going to go down that direction. And then is there
another direction that we would go down that may be complementary?
Absolutely. I think for me, and it's quite common practice, again, easier said than done is having
that stance of sort of no, but just no for now. You know, it's not always a hard no. If it is a
hard no, then this is why. But maybe we can look at this in six months, a year, two weeks, whatever it
is, you know, we're not saying that your opinion doesn't count. Relationship management is a big part
of that communication piece. And it's part of that narrative piece. So I think it's very important.
And we've talked about feature planning and communications and relationship management and
requirements gathering and all sorts of things already. You can't do all these things every day.
And I think one of the things that I like most about this job of product management is that almost
no two days are alike. Has that been your experience as well?
A hundred percent. I think this was one of the things that I was told very early on, like that
meeting that I had between my manager and PM and myself was never expect two days to be the same.
I think every day I sit down before I start my workday, look at my calendar, and there will
always be different things to be thinking about, to juggle. You never know what that next Slack
message is going to be or from who. I think the interesting thing for me is, especially around
the point of two days not being the same as I work. So at the moment, I'm at the FT, the Financial
Times. I don't own a product per se. You know, I'm not a conventional SaaS product manager where I have
this particular feature that is in my team's ownership, or I have this entire product that is
resting on my shoulders. The FT, you know, we have many different teams that will input into
digital subscription experiences as just one small part of a huge wheel. So there will be
different teams, you know, responsible for different parts of the product or different parts
of the experience. A team responsible for subscriber acquisition. I'll be responsible for, you know,
subscriber retention, which has happened, or, you know, currently I'm working on the homepage
experience. And there's many different teams who have input and say into how things are done and
how, you know, the estate, as we call it, is kind of split across. So it's a lot of collaboration.
And because of that, you can't make decisions on your own always. There could be lots of dependencies,
which means your day is always very different. You're juggling lots of different things. You're
speaking to people. And there's also so many other parts of just product management itself,
you know, in terms of like looking at data, user interviews, processing those interviews,
doing some opportunity mapping. So it's always, it's always fun. Keeps me on my toes.
That's interesting that you bring up that you don't have a specific product. You're in charge
of an experience across a variety of products, which I find that interesting because I'm in a role
kind of similar where I don't have one particular product. I'm spread across a whole ecosystem of
products. And in fact, I'm spread across a partner ecosystem of partner products on top of our
product. And so it's, you know, there's no sense of like the traditional product management of I have
an engineering team and we're going to deliver these features this month. It's really a much
bigger thought pattern. And I'm just kind of curious to get your thoughts on our roles like
these becoming kind of more the norm. Is that kind of where product management is going and kind of
away from that? Let's crank out five features for this product over the next few months.
Yes, 100%. This is a really great topic. What I'm seeing is more and more companies are
emphasizing that teams, especially engineers, engineering managers, designers, you know,
data analysts, whoever it is that's embedded in your team takes on more responsibility for the product.
That means a product manager is given that capacity and time and space to think more
strategically, especially if you're in an enterprise setting where, let's face it, a lot of
the times, you know, user experience is crucial, but also you're thinking about revenue and how we're
generating a lot of that or how we're retaining our user base or, you know, looking at those very
high level business kind of decisions and inputting into those that make really big impact away from
the day-to-day product management. And I think especially within the market that we're currently
in, a lot more of that is required from the PM. For example, with my team, I encourage my team to do a
lot of the ticket writing, you know, day-to-day. We don't have product owners at the FT, you know,
the product manager would have to do a lot of the tactical work and also a lot of the
strategic thinking as well. Again, I think it depends very much on what kind of a product
manager you are and what kind of an organization that you're working in. I generally see a pattern
of more autonomy for the team, write out those tickets, understand the estimation of the work,
kind of build out certain features. And then the product manager is overseeing that, thinking about
more of the strategy, more of the revenue, what's coming next, the roadmap at a higher level.
So I think that's really important as well.
It's really interesting to see how the field has evolved and how it keeps changing and how it's
going to arguably continue to change because I don't think it's going to be a stagnant field by
any stretch.
Absolutely. And I think especially with the introduction of AI, there's a lot more a product
manager generally now has at their disposal to be able to do a lot of this kind of thinking where we
might have more tactical ground level work being automated or shared across the team. A lot of this
workload is being dispersed to give that space to the product manager to innovate. I think that's
a crucial thing. Organizations, businesses, enterprises now want innovation at a faster,
more rapid scale to keep up with the demands of the evolving industry, keep up with the demands of
what AI can produce and what it can do for us. I think we've just massively kind of accelerated and
then now the PM has to kind of keep up with that is also my thinking. There's also the other more
darker side of what, you know, a lot of people shy of it from talking about is again, the market
situation and a lot of redundancies happening, roles being cut, you know, teams being shrunk and
that's putting more onto the PM. And then again, that's where you either distribute some of the more
tactical work that a PM would do, or you just take it on and you utilize AI and you kind of do that
whole package. So that's also something else that I've noticed.
Yeah, that's definitely out there for sure. Very interesting to see how far we can push AI
because when AI is right, it's amazing. And we're all like, wow, that was really cool. I got that
done fast. And when it's wrong, it's really wrong. And there's some things that AI is really good at,
like I'm going to give you a paragraph of text that I wrote, but I don't want to spend the time
to like make my next draft myself, improve it for me. AI is pretty good at this, but then like do my
research for me, write me a PRD, you know, it may get 70, 80% of the way there, but you still have
to check the work. And realistically, it's kind of like a fancy template at this point where, okay,
you could have had a PRD template that you just filled out yourself, or you can ask AI to generate
one for you. And it's kind of like, okay, that's about the level of where you've gotten. So I think
we have to be very realistic about what AI actually can do versus what people wish it did.
Yeah. A hundred percent. I think at the moment from like my own personal experiences, like I'm
a very pro AI, love what it can do, but I see it from a lens of productivity. Exactly what you said,
you know, help me write these tickets out, you know, user stories, something that I can do,
but it might take me an hour to do like five, six, seven, whatever many tickets, but AI can do it for
me in a minute, two minutes. I recently had a project at the FT that I was working on with my team.
And one of the things that, you know, is a perfect use case was to ask ChatGPT and kind of AI to help
understand certain data sets and, you know, group certain data sets together so we can change
however things were personalized on screen for our digital experiences. Very quickly, I noticed it
started hallucinating, right? If I gave it an Excel spreadsheet of 50 different topics, a hundred topics
or whatever it is, it would start entering in data or it will start removing data. So the reliability
is not there, but I think, again, use it as a crux for productivity where you can. The other thing,
for example, like what's new now is Lovable and Bolt doing a lot of this rapid prototyping or what we're
calling is vibe coding. Super useful, but 20 minutes in, I just realized this wouldn't, this wouldn't go
beyond the, you know, just a prototype that I could show to my stakeholders to kind of help them
envision what a product or what a iteration or a design could look like. It very easily started
to crumble when you kind of went into the weeds of the code. So yeah, I think it's still early days,
but use it for productivity and communication and collaboration where you can.
Talking about things like Lovable and some of the other products that are
basically out there to build code for you with AI, like you just tell it what your end state is and
depending on how much you know about code, maybe you give it a couple of parameters in here and
and then you get out the other end a working application ready to go, which is an amazing
promise. It's an amazing idea, but you have to be very mindful of the training data that's going in
to these language models that are generating all this code and you have to be a little bit concerned
at least that every single app is going to start to look and feel the same after a while because
the model is going to keep spitting out basically the same thing. To some degree, there's like this idea
that we should unify interfaces and that way you only have to learn like one interface, but this
stifles creativity. And if you just depend on a model that's had training data and we stop creating,
well, we're never going to get new creative data for the model to be trained on anyway. So at some
point that human creativity, I think is just so key to the process. And like you said, yeah, you can get
to a good start. It's great for a prototype or to say, hey, this is the idea. You know, it helps you
tell that story. Here's a visual of what I'm thinking. So I don't have to sit here and try and tell you
in words. I can show you here's what I'm thinking of. This is a similar type of flow and you can use it
for that type of thing. And it'd be amazing for that being able to say, hey, I generate me a prototype
that does the following 10 things and it's ready. That's that's wild. It's crazy. I mean, and I love the
point that you just mentioned about still needing that human creativity and input to not have generic
output essentially from any model. You know, you see these posts online on social media. Oh,
is this the end of product managers? You know, AI is taking over the product manager's job.
It most certainly is not. Exactly what you mentioned just now, like I could give it a two
line prompt and it will build me something that will be the same for everybody else.
But what I noticed is you need to speak to it like a product manager to be able to get exactly
what you want. So with Lovable, for example, I tried it, I gave it a few prompts and it just created
something completely out of whack, you know, from what I wanted. And it makes sense. They all just
use what you've inputted to process it. But if I used and I did this, use ChatGPT or Claude or
whatever it is to create like a PRD and break down, you know, those features, create some user stories
and then fed it that the results were day and night. I think they were completely different. So
that kind of product style thinking is not there in the AI, but it's always needed. So I think it's very
important. Very cool. So you teach and lead aspiring product managers. Tell me about how you
got started doing that. For me, community is a big thing. It's a big part of one of my personal
values and personal pillars in terms of where I stand within my career and also within product.
When I first got into product, I had some very good mentors. I went out on my way to kind of,
you know, speak to people, kind of build those relationships, understand product from different
lenses from different industries and building up kind of that network of mentors that I had,
all whom were very supportive, very generous with their time. And I noticed that about people
generally in product are kind of like that all around. But for me, it was about giving back.
So I had that good experience and I wanted to do the same. I love being part of communities,
tech communities, inside work, outside of work. And I would always come across aspiring PMs,
you know, people who see product management as being a very soft, skilled, focused career
initially, you know, your first impression compared to maybe being an engineer or a data analyst or
whatever it might be. There was always very common questions I would come across or, you know,
I would identify common patterns, certain pitfalls, reoccurring patterns and questions around the product
industry. So for me, it was all about making my experiences and my knowledge accessible to those
people, no matter who they are, just helping them along their journey. And once I did that a couple
of times, you know, it was something that I really enjoyed. And so I thought, hey, you know, let's
continue this. In terms of teaching, something that came to me initially, teaching product to these
aspiring junior PMs. I did a very high level kind of intensive course, very slide heavy a few years
ago. And that's where I really enjoyed it, kind of giving back, helping out these aspiring PMs,
and then just took it one step further, really. So now I can run my own bootcamp.
For me, the thing that I focus on helping people to understand product from an application point of
view, a real world, real life application, rather than just the theory, you know, and I always say
to people that I mentor, that I speak to, that it's really easy for you to go online and read on
LinkedIn and on X. And there's so much great content out there, but that doesn't always apply to you and
your scenario. It's not always reflective of what real product management is. You know,
going back to the point that you mentioned about two days are never the same, you know,
what do those two different days look like? You know, what are you getting yourself into?
So for me, and kind of the way that I do a bit of my teaching is around helping people to understand
those unique scenarios. You've said no, but your stakeholder is pushing back. What do you do?
Your team is resistant to estimating pieces of work, or your team is resistant to being onboarded onto
your vision for a certain feature that you have? What do you do? Those are the scenarios that people
are not prepared for. And I think for me, it's really important that you A, learn the basics.
Absolutely. It's very important about product. You know, there's certain things, frameworks,
et cetera, but that's not what product always is. It's not just, oh, I know how to use rice,
or I know how to create a roadmap. You know, I can use monday.com or whatever it is. That's not
product. You know, we, there's so many different moving parts to it. And I always want to make sure as
much as I can do my little tiny part and help people go away thinking like a product manager
and not just kind of regurgitating theory. I really liked how you called out all the content
that's out there on the internet. Certainly things like this podcast are adding to that level of
content that's out there. But just because something works at Google doesn't mean it's going to work for
you at your company, unless you happen to be at Google. There's just a lot of things that are
written from perspectives that this worked for me in this time at this place. And you're right to call
out that it's not necessarily going to work for the person reading it in the space that they're
at. But it's still good to have and to know that, okay, this works like this over here,
but it's not always one-to-one applicable. Exactly that. I think it's a double-edged sword,
right? So Google or like the big tech points of view is refreshing to see because it's constantly
keeping you on your toes as a PM. You know, I might read a post about how somebody is running a
workshop to kickstart a new product from a discovery perspective and how they onboard their stakeholders
in their teams. I might scroll up a couple of posts and somebody else is doing it completely
differently. And I'm always thinking, oh, wow, that's a new angle to things, you know, I could
add. And it's, you're, you're kind of borrowing from a lot of that content, a lot of those experiences
that are out there, you know, you're building onto your craft, onto your product experience
in this way. But I think for people who are into their careers, it's amazing. But if you're very new
or very junior, I think that's where you should focus on, you know, those real life scenarios and
applications whilst balancing the theory. And then when you're more comfortable that, you know,
go crazy and listen to all the podcasts, read all the books and do all of that stuff, you know,
it's always really useful.
You mentioned you run a bootcamp. How would a listener get connected with you to join that
bootcamp if they were interested?
So at the moment, it's sort of like an ad hoc basis. We do a couple of cohorts a year as well.
Feel free to reach out to me on LinkedIn. We can have a chat. I'm always really keen to understand
individual needs. And for me, the big one is always why product. It's something that I always
encourage people to understand and to ensure that they have an idea of why, because product for me
is a career that's a long game. It's quite a niche role. You have to really be invested into it to be
able to do well. And it's not always black and white, like maybe engineering could be. So for me,
understanding why people want to do it, what they want to achieve out of it, and just having a bit of a
chat, and then I can share more about the actual, the bootcamp itself, I'm pretty open. Just reach
out to me on LinkedIn and we can take it from there.
Excellent. So how would you say teaching aspiring product managers has helped you grow as a product
manager?
I think generally anywhere in the world, when you're teaching, it helps you kind of deconstruct your
own practices and understand them in a really clear, digestible way. So for me, when I'm teaching
somebody about how to build a roadmap or how to go through a discovery process, I'm also in the back
of my mind thinking, you know, scrutinizing my process or my own knowledge and understanding and
making sure that, you know, that's, is that exactly how I would do it whilst I'm also teaching it? So
that's really important for me. And it also helps me to enable the refining of those processes,
making sure that, you know, as I'm teaching, we're withstanding any real world applications that
that might go into. And again, it's not just a theory or a page in a book. So that's one in terms
of growth is, you know, reinforce those principles for me. I think the other reason around communication
and leadership is very important, especially when I first started, this really helps you to
clearly structure out, okay, today we're going to talk about this. I'm going to spend 20 minutes on
the first part of the topic. We're going to have a break. Then I'm going to make sure we go through
the rest of this. I've got this, you know, time slot, et cetera. It really helps me break down
that complex thinking of product generally into simpler terms. Oftentimes, you know, I've had
students where I would run through backlog prioritization, you know, what does deep mean,
for example, and students will just look at me with like a blank face, like they have no idea,
no context. And that's, you know, that's what happens. We throw around these buzzwords and it's so
normal for us as PMs, where it's alien to somebody who's completely new coming into this.
So being able to break the most simplest things down into being even more simpler,
you know, and that communication is really important and something that I think has really
helped me develop that across my time teaching. So that's also been really crucial. And then there's
always, you know, the reflection and self-improvement in terms of my own craft.
It's really, really interesting to just kind of see how doing that, how giving back to that
community has given you the opportunity to be reflective on your own spot in it and how you practice on it.
And I can definitely see how that would help you grow because you're constantly, like you said,
questioning how you do things. And is it the right thing? Is it what you want the future of product
management to look like? Or, hey, maybe we should change how we're doing this. And so this is today.
This is why this other thing would be better and having those conversations.
Yeah, absolutely.
So you've worked in both the private sector and the public sector. How is product management different
between the two? Because I suspect there's a lot of similarities, but we've talked before and there are
some differences.
Yes, there are. This is a really interesting and interesting topic. And it's something that doesn't
always come to light or isn't always spoken about is that, especially in the UK here, and for those
listening who are based in the UK, we have a very strong public sector or government product community
and practice. My first role as an associate product manager was within government, within the
Department for Education. My values and kind of what I stand for are like good experiences, solving
problems and also building communities and helping communities. A lot of that comes from those
foundations. And I feel really lucky to be able to start my career in a place where product is really
solid, you know, really amazing people, good practice. And there was a ground for kind of growth and
experimentation that I was a part of that really helped me build up those solid foundations for the rest of
my career. Now that I'm more into enterprise and the commercial sector, there are lots of differences, you
know, in the public sector. The key catalyst to building products is cultural transformation. I use that as a
broad term that would encompass things like technical transformations. There's a lot of legacy
systems within the public sector, user services, user needs, kind of making sure we meet those, being
able to ensure that we are accessible with our products and services to our users, you know, it's
really important. Kind of a bit of a side story. So a couple of weeks ago, my mum and I were kind of
chatting about passports, you know, hers was out of date, and it needed renewing. And it's like, oh, we need to
do this, you know, we need to get it done. It's another life admin job, and it will take us days and days. And
there's a sense of panic, and we have to get the form, and we'll have to fill the form out and send
the form out. And I realized, I think the last time my mum did something like this was many, many years
ago, you know, where you'd go to the post office, and you'd pick up one of those forms, and you'll
fill them out. And then it was only after she finished ranting was when I kind of said, you know,
or just take me 10 minutes online. And you know, your passport will be here like in two weeks. And that's
exactly what we did. So now it's one of the best services that we have in the UK, is this service to
kind of apply for a UK passport, get one urgently, or, you know, renewing it, and it takes 10
minutes, perfect online service, perfect example of, you know, what good products are.
I'm jealous. I wish we had that here.
It's amazing. The UK has a really good government digital service.
Tell us about the UK's government digital service and how any product manager in the world can use
that as a resource to help get their job done better.
You might have heard of gov.uk. That's kind of our main brand, right? It's where the services are
built and how they're launched. So gov.uk is open source. It's all about reusable components,
accessibility, world leader, I would say, in building public services, government digital service.
What's really interesting is that the government digital service, so GDS, supports over, I think,
15, 1600 live websites globally. There's been a massive influence on some of the key government
digital services across the world. So USWDS, the United States Web Department, I want to say,
a web design system is heavily influenced and draws from gov.uk. Canadian digital service is based
heavily on the same. The Italian government's design system is also based on GDS design patterns.
So it's a very kind of all-encompassing, this is what we stand for, accessibility, user needs,
user services. It's a whole manual that anybody can access online and it's what we use to kind of
build our services on. And there's a lot that it can go through. If it was a book, it would be
humongous. It would be volumes and volumes. It talks about good agile practices, design. So we have
a very thorough design library that's used across all of our public services on gov.uk. We talk about
how best to do prototyping, how to build design patterns. And that's where a lot of these
governments I've mentioned have kind of drawn inspiration from. We do something in the public
sector in GDS called service assessments. So when you are building these public services or online
products, you have to go through a standard, which is, I think, it's like 13 or 14 points. And you go
through an assessment to make sure that you meet those points to be able to ensure that this product
is fit for purpose. One of the things around government services, especially in the UK is
it's very centered around user needs. You know, we have to build products that are not just for our
most tech savvy users. So if I go back to the point about my mom and renewing the passport, although I
kind of did it anyways, it should be built in a way where my mom can go online and click through and
kind of do a lot of these things itself and gain the desired outcome that's needed in minutes or in a
very easy way. So that's how all products are built on gov.uk. And it's very, very important.
It's crucial. There's huge amounts to go through here, even with capabilities, right? Product managers,
delivery managers or slash scrum masters, user researchers. There are frameworks around how
this is what we're looking for in an associate PM. This is what a head of product should be doing.
You know, what kind of level of skill do they need and how should they be working towards that?
So it's very set out, especially a lot of these benchmarks, frameworks, building services.
I see it as a 360. So it's always giving people, especially in tech and government,
a reference to work back towards, build towards a certain standard and also make sure that services
are scalable. You know, they're all built on the same stack. Anybody can come in and pick up
somebody else's service or product and kind of take ownership because it's very well thought out,
which I think is excellent the way that it's done.
No, that's really cool. I had no idea that the UK had such a resource. Yeah,
it's available to anybody. So that's really cool. Definitely drop a link to that in the show
notes for this episode.
Amazing. No, I definitely will do. And I just want to point out, I think I mentioned this to you,
Karl, before this podcast and our last catch up, the profession capability framework. I introduced
that to Lenny a while back.
Oh, okay. Cool.
So you heard it first from me.
That's a good claim to fame.
Yeah, that's it, right?
But no, I kind of, I keep going back to service and that word, but it's very important within
the public sector product building because we think about services as the end-to-end experience,
not just what does this slice of the product do? Or, you know, what does this feature do? And
we're not thinking about how it kind of joins up the user journey around it or other considerations.
Service is kind of the heart and center of GDS and public service building.
Awesome. So Adel, one final question to help our audience get to know you a little bit better.
What is one goal you hope to achieve in the next year?
Oh, that's a great question. Is that personal goal?
Can be. Personal, business, your choice?
Um, I think it would probably have to be something to do with AI and being able to master AI in a way
where it kind of excels my product thinking and product skill set to the next level. So we kind
of briefly touched upon using a lot of these kind of gen AI tools like Lovable, Bolt, whatever it is
to build prototypes, et cetera. But I want to incorporate that more into my workflow and then
also support the kind of organizations that I work for, you know, the business in terms of achieving
their goals with the use of AI as a support tool and having that level of technical knowledge beyond
just being able to write a prompt and output a prototype. So I think getting more comfortable
with AI and at a deeper level than just the surface.
Very cool. Thank you so much for coming on the show.
Amazing. No, thank you. This has been great. Thanks, Karl.