Unlocking your internal tools

Good afternoon, everyone.

Good to see you here.

It's a great talk so far.

Hope ours can match the caliber we've seen so far.

Today we want to talk to you about being product led and, adopting product thinking, especially when it comes to your internal capabilities.

We really want to help you get the most of your internal capabilities and tools.

And, we're just going to start by talking a bit about ourselves.

So who are we?

Both of us are from Terem, Terem's a digital product development strategy firm.

We work with enterprise, to bring their product goals to life.

We do also work with scale ups and government occasionally, mostly enterprise.

So we modernize applications and platforms, build new digital products from the ground up and, bring new capabilities and ways of thinking into organizations.

So it's really valuable having, being able to work across orgs.

We get a lot of insights.

We see different things, different patterns, different teams.

Hopefully we can share some of our insights with you today.

Just a bit about myself, 20 plus years in software architecture and development, gravitating more towards architecture over time.

I really liked that aspect of software development.

I'm a principal engineer at Terem currently, and I really work across industries, mostly on, bespoke software solutions.

In my personal time, I have two kids, two dogs, two cats.

They take a lot of my time and attention.

I also love Brazilian Jiu Jitsu, reading books.

And, riding dangerous vehicles, ideally with two or one wheels, I can talk to you about the one wheel later.

Over to Beck.

Awesome.

So I'm Beck.

Hey guys, I hope you've had a good lunch.

I've had about 12 years in the project and program delivery space, specifically more agile delivery management over the last 10 years.

I've worked with a lot of enterprise organizations to deliver products and platforms in various forms.

We've worked on, the ATO's new Apogee platform.

Delivered modernization programs for Qantas, NYOB, QBE.

I'm a partner at Terem.

And in addition to work me, I also have two kids, two girls.

One is just turned into a teenager.

So I'm sure that my gray hair will come through soon.

And I also have a crazy chocolate Labrador.

I love travel, love music, love climbing.

So good to be here.

Thank you.

All right.

Ah, it's me.

Tag.

I was it.

So what is the problem that we wanted to talk about?

Essentially internal capability platforms.

We know that they're often overlooked in favor of external and customer needs problems.

So a lot of the time we've all been in an organization where there is an internal tool that we just don't like using.

We roll our eyes.

We all sit there and go, Oh yeah, that one, it's got, its place, but we all secretly giggle and get annoyed when we have to do something on it.

But organizations do continue to put effort into those platforms because we need them.

And the upshot is yes, we probably do need them in some way, shape or form, but you only need them if they're actually providing value, they're actually going to help you.

So taking a product led approach to your internal tools and capability platforms can really help to make more efficient usage of those resources.

Can boost adoption, streamline your workflows.

Decrease the number of eyeballs you get, increase your productivity, make data driven decisions, and above all else, you can actually truly provide value to teams through increased internal productivity.

So we're going to start with a couple of definitions just so that we're all on the same page and just to underpin what we're going to talk about.

So what is a product?

This is one of my favorite definitions because when you read it, you have to then read it probably two or three times to completely understand it.

So I'll give you all a moment.

So we're thinking, we're talking about product led thinking.

What is a product?

It is something that your users acquire from you in order to obtain the benefits that possession of that product brings so they can reach the goals those benefits will help them attain.

Has everyone read it twice?

Good stuff.

Most of the time, organizations talk about products being their external offerings to customers.

So it's their web apps, their mobile apps, it might be a box of cereal if it's a physical good.

It might be an insurance product, which is more of a service, or it might be a software, product.

But a product can actually be anything that you're supplying to someone else to help them solve a problem.

So when we apply that lens to internal capability platforms, a couple of the things to note are that your users are internal.

They don't have any choice about the products that you're forcing on them.

But they are actually a captive audience.

You have direct access to them.

So that gives you a really good basis and foundation for being able to talk to them.

It's really tempting because user and users are internal and they're not paying.

And you, they don't have a choice about whether they use the product or not to, not try as hard or for an organization to just oh, that's easy.

It can just sit there.

The people that work here have to use it anyway.

So we'll just, we can live with the problem.

However, it's a bit of a trap because you're essentially shortchanging yourself.

You're shortchanging your users, the bet, the business or the organization that you work for is the beneficiary of the value of the internal capability platform, if you are not providing the true value you're not providing the true value to yourself.

So don't shortchange your organization by shortchanging your internal users.

What is product led?

So being product led means focusing on these four areas here.

Providing true value to your users, putting them first and hyper focusing on them above all else.

It means maturing through iteration, constantly learning, not being afraid to fail and get it wrong.

Starting high level, finding the right nuance, the right detail and doing that over time.

It means rapid early validation.

Checking in with those users, talk to them often.

The great thing is, again, as I said, they're in the building, they're on Teams.

You've got direct access to them, so go and talk to them.

And discipline prioritization.

Prioritizing user experience, prioritizing self service, prioritizing features and capabilities that are really going to help your internal teams.

And what do we mean when we say internal capability platform?

We mean an integrated system or framework within an organization that provides the necessary tools, capabilities, and services to support various functions.

So it might be a design system that is an internal capability platform for front end development.

It might be an internal API.

It might be an automation that you put to help them achieve a goal.

We use these to streamline operations, to foster innovation, to enhance productivity and overall reduce cost.

What happens when we don't think product?

We don't, we can get low or poor user adoption.

We can waste resources.

We can lose revenue.

We can get a damaged reputation.

And when we apply that thinking to internal capability platforms, these are the things that it can lead to.

It can lead to users who don't use a capability.

If you're not giving your development teams a capability that is easy to use, they'll probably just do something else.

They might copy and paste.

They might, go and find a way that doesn't sit within your, organizational guidelines instead.

You'll waste your resources.

You're essentially spending time to create an internal capability that people aren't using.

Why spend the money?

You're missing opportunities by asking your teams to spend time on making up for the lack of that product or for the lack of what it doesn't do for them.

They're missing out on the opportunity to do other things, and that might be for your end users.

They could be rebuilding something or pushing something out to market instead of rebuilding an internal capability.

And it also leads to a bit of damaged culture and collaboration.

Again, we all kind of giggle when we say that we'll roll our eyes at that internal platform, but over time, that means that it causes a big hit to your culture.

Teams who don't respect each other because they, there isn't a feeling that they understand how each other work.

Maybe it's platform teams who get a bad reputation.

Maybe it's employees who are annoyed because they're using a tool that you're forcing on them that actually makes their job harder and that then they leave and you have to recruit again for that.

So it can lead to really damaged culture and collaboration as well.

And what this all leads to is it impacts your revenue and your profit.

These things have a direct and indirect impact on your organization, organization's bottom line.

So it's worth thinking about the ways that you're, providing capability to your internal teams.

So where do we start?

A big question.

But it actually starts with you.

Let me clarify.

It starts with your organization.

The first step is really to have a think about the context and environment in which operating.

What are the internal platforms you need?

What are the capabilities?

What are the, what does the organization look like?

So we'll step through a few of these things to have a think about.

Conway's law basically says that any organization that creates an internal tool will inevitably produce a framework whose structure is a copy of that organization's structure.

So the first thing I want to say is consider your current structure and your processes, but do you want your internal tool or platform or internal capability to work the same way that your organization does?

Because that is what you will tend towards.

If you want to do something different, you have to really put effort into doing something different.

Consider the maturity of your organization and your teams.

We've got to build a platform or a tool that is right for them.

If you have a low maturity team, you might need to take them on a longer journey.

You might need to put more guardrails in place.

If you want to… If you have a high maturity team, you may be able to set them running with a few tips and tricks, a few pointers, but actually set them running and there'll be quite autonomous in terms of what they can deliver.

Baseline your maturity.

So start here, baseline your maturity.

And it's a good idea to, to redo this again, when you've provided the capability.

Consider how you're going to operate the platform or the tool or the capability that you're wanting to install.

You've got to get your governance right so that it remains an active, and evolving part of your ecosystem, part of your processes, part of your development.

So think about whether you want to have centralized versus decentralized versus hybrid delivery.

They each have their own benefits and negatives.

But what's right for the tool, for the platform that you're creating, for the capability that you're creating, and what's right for your organization.

You might also want to consider how you fund initiatives.

So a project based organization can actually work against you when you're developing internal capabilities.

And the reason behind that is a project or program is usually KPIs on meeting the scope listed in an SOW.

They have no obligation whatsoever to leave the company or the organization in a better place than when they started.

So if you are a project funded organization, it's worth having a think about how funding relates to the capability that you want to provide and how you put the guardrails in place to make sure that future projects and programs can contribute and keep going with that capability.

And also consider the investment the organization wants to make in a capability platform or tool.

It's really important.

It's one of those parameters.

Sometimes it's what makes or breaks a business case for an internal tool or platform.

But it's one really important thing to note.

And I just want to note here that if I remove the assumed investment line, it is expected that a new internal tool will decrease your productivity for a little while.

As you get used to it, so just make sure that those in charge of implementation or those in charge of actually approving business cases are aware that you'll probably take a bit of a dip, might not be a huge one, might just be a small one while you're training.

But it is expected that productivity will take a little bit of a hit as you're putting in new systems.

And the other thing we want to consider in terms of the, company or the organization in which you're, sitting is consider your scale.

So this one's particularly relevant when it comes to, larger, internal platforms.

Do you need a large, all the bells and whistles internal platform?

Do you need a design system that has everything in it?

Do you need a small API, which actually just is reusable by three or four teams?

Or do you need something that's actually reusable by one team?

So consider what the scale that you are building towards is.

Awesome.

Simon.

Tag.

You're it.

Thanks, Bec.

A lot of the talks today have been highly technical and I've learned some amazing things, a lot of things I want to research later, but what I'm going to talk through now are some tips, for applying, a product led lens, but without getting into specific technologies, I'm worried more about, the thought process and, just the general way you go about doing things here.

So to kick things off with our first tip and very dear to my heart as a longtime engineer and architect is make pragmatic decisions and understand the trade offs.

One phrase I hate to hear, and it's not because there's anything wrong with the phrase, but there's, a lot of hidden meaning, is best practice.

Now, best practice, if it comes to, web standards, accessibility, all of those things are great.

They should be carefully considered.

But sometimes that masks what people truly mean, which is there's only one right way to do things.

And that can happen industry wide where you look at architecture patterns that just take over all orgs and they may not be a good fit.

Through to what will happen at one organization where we've done this before this way.

This is just how it's done.

This is the correct way.

So you really want to avoid that.

Usually when it comes to making a decision, there's more than one good way and definitely more than one bad way to go about it.

So consider that.

And the best approach for someone else may not be the best one for you.

And to elaborate on that, the best approach for you on your last project may not be the best approach on the one you're working on now.

So really important to stay flexible and to adopt flexibility over rigid best practices.

And finally, on that point, you definitely want to tailor your solutions to your organization's needs.

So that's size, context, lifetime, all of that stuff.

The next thing here is understand and manage trade offs.

So in an imperfect world, we can't build perfect products.

So you always have to balance competing priorities.

And you've got the classic three here.

You want fast, good, or cheap, pick two.

You can't have all of them.

So just understand what you're doing.

There is no perfect option.

Make informed decisions that are very aware of the tradeoffs and make sure that you get broader agreement within your org, or at least if it's entirely your decision to make sure you at least communicate those tradeoffs.

So people aren't stung later, every decision you make involves tradeoffs.

It's good to own those and be aware of them rather than discovering after the fact.

Definitely make sure your decisions are context aware.

So again, that's things like team dynamics.

The requirements you have at hand, as well as the timeline and the lifetime.

And these last two can get very tricky.

You don't want to overbuild something that you know is a bridging product or capability, and, you don't want to shortchange your long term users because someone's rushing you to get something done, but this product's expected to live for a decade or more, then you'll want to push back and go, actually 'this is going to be around for at least, 10 years let's make sure we do it right.' There's some key things we need to put in there.

And finally here.

Just emphasize simple architecture.

So you want your architecture to be maintainable and scalable and avoid over engineering.

I'll speak a bit more on that later, but, in my experience, over engineering tends to come from seeing one vision of the future and starting to plan for it.

Whereas ideally you stay small and agile with what you're building with your architecture.

So you can actually adopt any number of possible futures that may arise that you're not even aware of now.

So things can play out in a certain way and you might want to plan for that, but can play out in other ways as well.

So stay flexible, especially when you're starting out.

So on to the next one, still talk about architecture here.

You want to be really sensible.

So understand your end users.

Can't say this one enough.

It's very easy to be tech focused, especially when you're building a tech product, very easy to be tech focused.

You might start with, we need it to be this framework.

We need styling to work in this particular way.

This is how we integrate it.

And, it's really easy to jump into solution mode.

We need this thing and this is exactly how we're going to build it.

Cause we're technically minded and you can put those pieces together, but you need to make sure your user's needs come first.

And technical decisions are important, but make sure they don't override or ignore what users actually need.

And it's twice as important when the internal users, as Bec mentioned, they can't run away, they can't use another product.

They have to use what you give them.

So don't disrespect the position you're in and make sure you look after your users.

Another thing you can do here is use empathy mapping.

Understand the needs and wants of your users, of your customers here.

So map out user journeys and consider the state of mind when users are there.

What are their motivations?

What are their frustrations?

One thing I really like here is what are their triggers for delight?

What are some things you can do where they go, Oh, that's awesome.

I love this.

Something that will make them share the product or talk about the product.

Try and put those things in there.

Try and make that experience a nice one for them.

So next thing we can do here is take an outside in approach.

And this is really just another way of saying focus on your user's needs and not the technical building blocks.

Tech is important.

It's super important.

I love tech, but ultimately tech serves a human need or it doesn't deserve to exist.

So focus on that.

Talk to people, get feedback, talk to potential users, consider and map out real world use cases.

So actually get real examples of how this will be used.

Make sure you're meeting those use cases.

So that sort of ensures that what you're building is effective.

You don't want it to be abandoned or unused or make someone's life more difficult.

You can, the worst thing you can do is build the shiniest platform that nobody uses.

So we want to avoid that.

Another thing to do here is to research similar platforms.

So while you do want to be pragmatic and make decisions that are directly relevant for your org, you can't just, you need to consider what's already done.

You don't want to build everything from scratch.

You don't want to reinvent the wheel.

However, do pragmatically copy, borrow, steal, where it makes sense for your end users.

Make sure you can also scale and flex.

So again, touching on the architecture that can change, make sure you just make it as simple as possible.

So all future states can be coped with and make it modular as well.

Make sure as well that the integration is seamless.

So start with your API, start with your contract, start with, how do people use this?

What is the mechanism by which they integrate with our platform, with our product, and make sure that's in place and, again, prioritize your team's needs over just what you as the product team want to build.

Finally here, and put your hand up if documentation is your favorite thing.

It's not, but it's really important, especially for an internal product.

Maybe it is for someone here.

I'd love to talk to you about documenting my projects.

So make sure what you build isn't out of date.

Your documentation matches your actual product and that you keep it up to date.

There's a final concern here which I'll just skip over.

Security and compliance.

We're doing a front end stream here, so not a huge concern, but if you see anything on the front end, then make sure you speak out and get that resolved.

So a third tip here, as you would with an external product, make sure you can actually iterate.

So the quote here, because the design which occurs first is almost never the best possible, the prevailing system concept may need to change.

Therefore, flexibility of the organization.

Is important to flex, effective chain, design.

Sorry, it's So look, you need to make sure that you can iterate.

What you first put out is not what you end up with.

Products go through a life cycle.

You need to be aware of that life cycle and you need to be ready to change.

So you don't want to be precious about your ideas.

You don't want to be too tightly coupled to things you've put out there.

And it's okay to retire things.

Try a different approach and be flexible.

So next, make sure that you can measure.

Metrics provide us with objective intangible data that allows orgs to make informed decisions.

So you want to make sure you are capturing sort of two kinds of metrics here.

You've got program project metrics and product metrics.

Program, project metrics, are measuring the success of an initiative or piece of work.

And the product metrics measure the health of the product itself.

So that's not the usage of the product, that's the adoption of the product.

And it's important to be measuring that if you're wanting to improve.

And make sure you're learning.

You need to make sure if your product's successful, you need to know it solves the problem your users have.

And you need to be receiving feedback.

Make sure you incorporate this at every stage.

Make sure you're constantly open to it.

But also act on it.

You have to use that feedback to improve your capabilities.

The more you listen, the better employees think you are at understanding them.

There's a study here that showed the effects of listening, its increase on engagement and efficiency, as well as a reduction in turnover and errors.

Given that your internal system is an internal product, the users are internal, you need to make sure you're asking people for feedback.

There's a lot of ways to do that, but just make sure you listen.

It's very important to listen, understand people's problems.

Do your best to remedy them.

So a few things you can do here.

There's a few ways of getting feedback.

You can directly observe behavior.

You look over someone's shoulder.

Keep in mind that doing so can change their behavior.

I know there are times I've worked on something and someone's watching.

Shoo them away so you can actually get it done.

There's some indirect measures you can do as well.

And of course you can pay attention to what people do and what people say.

There's a lot of noise around all of this, so you can end up collecting numbers that don't tell you the true story.

So it's important to be able to consolidate all of that, look between the lines and get the true feedback you need.

But you want to consider the end to end cycle.

So how is this going to be intro'd?

There's a learning stage as Beck, mentioned.

What does retiring this product look like?

What does refreshing it look like if we publish a new version?

What does maturity look like?

And, are we tracking different metrics?

Do we care about different things at different stages?

And look, the first product you put out is not the one you end up with, so don't be afraid to make mistakes.

Have some support mechanisms, so prioritize ways of getting help.

That can be both you can have casual and formal channels.

You can have Support desk, you can have wikis, knowledge bases, you can also have more casual ways.

You can have nominated experts, hopefully very friendly ones, that people can talk to.

And, put metrics in place wherever you can and monitor them, and make sure you have support that's appropriate to your organization.

Again, teams that are newer, teams that are immature will need a bit more support.

Make sure that's in place for them.

Finally, again, don't be afraid to fail.

You're going to get it wrong.

Nothing you do the first time is completely right.

It can't be so don't let that stop you from putting, your product out and iterating on it.

I think just on that last point as well, it's really important to note that with internal capability platforms, you're actually in a really great spot in terms of product development, because you do have access to those users.

You've got really easy access to them and they're going to tell you what they think.

So they, you typically also have the most forgiving set of users.

Making a few mistakes on them is okay.

As long as you listen and you act on them, and just keep iterating again.

Awesome.

We were going to run through a design, a case study, of an internal capability platform as a design system.

We are running a little short on time.

So I'll try and fly through this and talk very quickly, which I'm very good at.

Essentially the case study, we had a global insurance company, who operate, B2B, B2B2C and B2C sales for insurance.

We had nine months and they came to us with a task, a development task, which was to build a front end development library that digital development teams could use to increase speed and productivity.

They were seen as being quite slow, and that was, was very much, a task that they brought us to, to try and help them with.

Now I ran this program over nine months, and the first challenge was to actually get them to move from thinking about this task that they wanted us to do.

They wanted a library.

That was all they came to us with and get them to start thinking about an outcome instead.

So what we came up with in the end was actually to provide a series of front end development libraries or resources, a framework, that would increase the productivity of digital development teams globally, would cater for the end user customer, like the people who are actually purchasing and using insurance or using these applications and the development teams as to direct different users.

It would scale quickly.

They were a global organization and that was very important to them.

And it would be easily maintained and supported by the teams that they currently had within the organization and what we came out with, as you can see the difference between these two slides, this, what they brought to us was the idea of creating a library, which had components in it.

What we came out with was understanding the outcomes that they truly wanted from it and the way that their users worked.

We came out with this outcome that is much more than just a component library.

So it became a framework, it became a living product, it became, into being.

Whoops.

The aim was to really discover and build not only the components that you can see here, the primitives, so the UX UI components, small API components, small analytics, and logic components.

It was also to then put them into patterns to create smart components, something like an address lookup component, and then go all the way up to front end, so a micro front end for payments.

Now, how we did that was we went through this process.

I'm not going to go through all the bits and pieces in behind this because time and I will get the music will start playing soon and I'll be shoo'd off the stage.

But if you do want any more information on how he did this, I'll be sitting down at the front afterwards.

Please just come and find me.

But essentially we followed this, this process, we considered everything.

We adopted sensible architecture drivers.

We had pragmatic decisions and we talked about the trade offs.

We build measured, learned, iterated, we had cross functional teams building this, internal capability.

We considered the end to end life cycle.

And what that looked like was not only the component library and the technology there, not only how to developers and designers implement, design new things, add, but also things like training, onboarding.

How do we make sure people can use this capability ongoing?

And how do we support that as well?

So support and maintenance.

We went through the don't be afraid to fail.

But essentially the outcome that we came out with was fantastic.

In nine months, we delivered all of these things.

We delivered multiple component libraries that will continue to be iterated on over time.

We, delivered adaptable design tokens that allowed them that flexibility, of multiple brands.

We delivered living style guys sandbox, and documentation that was all in one place, which our developers or the developers were just so pleased about.

We developed an appropriate governance framework.

We built in automation and quality all the way throughout automated tests.

We were able to build in analytics so that it was all in one place.

People didn't have to think about analytics being an afterthought.

We built all the onboarding guides, the training, the how tos, the support channels, and we built a casual, or a less formal front end development community and the support channels around that as well.

So the community of practice that went with it.

And.

At the end of the, we not only had a great product, internal capability product, we also had a really content and involved, development team who were really excited about an easier way of working.

So we'd not only done all of these things, we'd also improved the culture within the organization, which was fantastic.

Okay, before I get in trouble, for going too long, the conclusion, I'm just going to pop this back up here, which is really follow these steps.

If you want to try and build a internal capability platform or a tool, if you want to do that in a product led way to make sure that you get the best value of it.

Follow these steps and there's a dig at Simon here in terms of best practices.

Make sure you are not blindly following best practice just because that's what other organizations do.

Make sure you are being pragmatic and thinking about the best way to do this for yourself.

If you want more Terem.

Tech, there's a lot of insights.

There's a lot of playbooks and you can find, all of the material, that's on here at some point.

And if you want to get in touch, Simon's a bit shy, so he hasn't got his QR code here.

But, if you want to get in touch, please do reach out and, and, connect on LinkedIn.

Thanks everyone.