Imagine going for a walk through a park in early summer. People are gently strolling around. Couples and families are focussed on each other, joggers jog, dog walkers gingerly pick up droppings and some people stare at their phones doing their own thing.

Most people follow the paths laid out in the park, particularly if they are phone-fixated and need all the help they can get to stay on course. But, do you follow the path exactly? Or are you ever tempted to branch off it to get to somewhere interesting?

If you are tempted to meander off, then possibly you’re just a contrarian who likes going their own way and have little concern for convention. Or, it could it be an indicator that the path is not as well designed as it should be, and you’re not such a rebel after all. Sorry to break that to you.

The beauty of observed human activity

There are several interesting studies of how people find their own way and the patterns that form. I particularly like Klaus Humper’s Lauf-Spuren (Running Tracks). It shows photos of where people have run through fields in the short-lived snow amongst other places.

The beauty here lies in the way that we can momentarily see fragile traces of human passage through fields of snow. These ephemeral trails are susceptible to being erased permanently by a thaw or further snowfall, possibly only to be etched in once again as the next winter and another set of runners’ feet arrive.

Worn out grass can provide a more permanent marker of people’s need to get from one location to another. Grass being a more resilient surface takes more footfall and more time than snow for tracks to become a feature.

Moving from de facto to concrete

The worn out grass shows desire lines and the process of subsequently paving over the worn-out grass has widely become known as paving the cowpaths, a business metaphor for making something concrete that has already become de facto.

So how does all this relate to platforms? These desire lines show us what people need and that those needs aren’t being met. The pathways enabling those needs can be made more concrete if the investment appears it will pay off.

My experience is in tech solution platforms and I’ve started imagining tech platforms as multi-dimensional networks of paved cowpaths, each of which represent hard won experience. It could be said that platforms see what is needed most often and make it available to anyone who consciously or unconsciously has those needs.

platform: a raised level surface on which people or things can stand

Oxford Languages

Taking the literal interpretation of a platform above and transposing the idea into the tech world, we get something on which we can add, or build our own virtual “things”. These things could be dating profiles, room lets or business solutions, to name a few.

Data collaboration platforms such as SharePoint, Airtable or LiveDataset (which I personally worked on) all solve problems that people are encountering on a regular basis. They enable collaboration on tabular data using familiar spreadsheet-like conventions. These platforms also come with data visualisations. They have permission management, user authentication and lots of generally useful stuff.

I’m vastly over-simplifying, but my point is that platforms get you to a solution quicker. What they don’t do is get you all the way to a decent solution out of the box. Some legwork and knowledge is needed to turn that into a usable solution even if the aim is just to implement something simple, such as a one-off collaborative party planner.

Think of it as using public transport in an urban area vs a private car. While transit networks are expensive to build, they are often cheaper to use, readily available to the masses and sometimes faster. Having said that, you generally have to walk a bit at the end of your journey to get to where you want to be.

Platforms represent a hard-won path

Most platforms didn’t get where they are by someone having a brilliant idea and then just implementing it. Someone had to walk several paths, make some of them concrete and see what wasn’t quite working by watching where people actually wanted to go. Then they had to create newer, better paths.

Platforms are hard and expensive to get right, but the privilege of being a gateway to a multitude of solutions can often compensate for this. The rewards come by being an indispensable base that stuff gets built on especially when it’s simply too much hassle and expense to go elsewhere.

I love reusability. I love being able to do the work once and to see it used repeatedly. Perhaps I’m a little lazy, but I don’t want to keep solving the same problem over and over again. Platforms do this by providing the 80% underlying nuts and bolts to a solution. Sometimes that is good enough and other times someone will be willing to pay a lot more to have it their way.

Meanwhile, back in the park

Back to our urban park, which could be called a “physical leisure-enablement platform” to honour my increasingly stretched metaphor. A park generally gets built once and then evolves slowly to reflect the needs of the people in the changing city that surrounds it.

It will never perfectly meet the needs of all its users, but it is good enough to enhance their quality of life a little, to host events and support businesses such as cafes and kiosks. The park can always be improved further as gaps appear between what it offers and what people demonstrate they want. People may speak up directly to the relevant local authorities or demonstrate their needs indirectly through actions such as walking on the grass.

This certainly tallies with my own experience that no matter how many killer features you think you are adding, it will never quite become the one platform to beat them all. There are just too many possible variables and solutions for all of those solution-specific features to converge into something platform-worthy.

If we can accept the less-than-perfect, we can probably get to where we need to be faster and cheaper with a platform than starting out with nothing. We can still go elsewhere for a more specific experience, but the cost and uncertainty of building from the bottom up is nearly always greater than you might think, not to mention technical debt, but that’s another story!

Product managers have to manage people, often using indirect influence. These people may be stakeholders, UX people, technical people, marketing and probably their boss too. 

Some product managers may even be “lucky” enough to manage a team or other, more junior product managers. Whichever way you look at it, a product manager is going to have to manage other people in some form or other.

Given that we can’t hide from human interaction, let’s take a deeper look into the different relationships a product manager might have to handle.

How to handle your boss

Probably the most important relationship you have is with your boss or direct supervisor. The quality of the relationship you have with anyone directly accountable for your work, whether it’s a CEO or a more senior manager, will have a direct impact on the quality of your working life. Chances are if this doesn’t feel right, everything else about your role may feel a bit wrong.

It’s important to remember your boss is a person and is in that position for a reason even if on the surface that doesn’t appear to be due to merit. They have multiple pressures, their own personal agenda and won’t always get things right. Just like you if you were in that situation.

Now that you see them as a more equal human, your mission is to help them fulfil some vision. If that vision is not clear, work with them to make it clearer. You’ll both end up happier.

Be prepared to be more organised

Be aware that any time spent planning what you want to say and and the path you would like the discussion to take can get your conversation closer to the outcome you desire. Chances are, your boss won’t prepare so much for a meeting with you and will wing it because they have other priorities.

This is your opportunity to be more organised, take some control and manage the relationship upwards. Most managers will be grateful for this as it gives them less to worry about. Even those with peculiar control freak tendencies might might be pacified if they sense you have everything under control.

Healthier, happier relationships (and use data)

You may be unhappy about not having sufficient resources, the direction given, a lack of clarity or not being allowed to sit near the window. It’s generally best to be outcome-focussed and suspend any judgement as to why your boss is doing such-and-such and explain your position clearly and how you or your work are impacted.

For nebulous, opinion-based discussions have data available where possible, otherwise you’ll “lose” or in more positive terms, get less out of the discussion than originally hoped for.

Data will always trump speculation or statistics made up on the spot from some vague memory or intuition. Data gives both of you something concrete to latch on to and helps get around personal cognitive biases, which we all have.

Be outcome-focussed

By managing your own emotional state in any discussion you can focus on the outcome rather than any short-term emotion. There are several techniques to do this and even just pausing to take a couple of deep breaths can be enough to become more centred. Because ultimately, everyone wants a good outcome.

How to handle peers

In my experience peer relationships may appear to be the easiest to handle, at least easiest superficially, but can be problematic in reality.

On the surface, these are people you are familiar with, possibly spend a lot of time talking with, and hopefully have an equitable relationship with.

The lack of any obvious line of authority through the relationship can sometimes mean that, if unchecked, there are opportunities for political power plays to emerge.

First, understand that they may have different motivations and a different agenda to you and don’t assume they think the same way either. It’s generally better to rise above any issues and focus on outcomes for your product. This means putting yourself and your ego second so that the results speak for themselves. I find most people respect this sufficiently to then get out of the way accept what comes. After all, no one really wants to deal with competing egos.

How to handle techies

Techies are often not your average guy or gal, but yes, they are human too. The best tech people, apart from having exemplary tech skills, are the ones that challenge their assignments and your assumptions. They do this for a reason and it’s generally not to be deliberately difficult.

Good technical people need clarity about what it is that they are trying to achieve because this will give them focus and some clear outcomes to aim for. Focus is useful because it can allow the tech person to get into a flow state where they are at their most productive. Also, clear outcomes mean that we can define when something is done and that “doneness” can be tested. And good testing makes for good, working software.

How to handle stakeholders

Stakeholders vary in their enthusiasm for what you are trying to do. Don’t expect them all to be equally excited all the time as they won’t be. They will be on your back though when things don’t go as they expected, rightly or wrongly.

The key with stakeholders is communication in a form that they can easily consume. Some say it’s better to over-communicate as a product manager and while I agree that this is better than under-communication, the output can just appear to be noise if it’s not structured in a way that your target can easily absorb.

Personally, I experimented a lot with the communication I pushed out and spoke to people about what they thought of the information my team sent out. Usually the most insight came when things went slightly wrong.

For example, there may have been some user interface change and a client wasn’t aware of it and it had an impact on their business. Clearly, and quite rightly, they weren’t happy and someone such as an account manager would have to step in to limit the damage.

These are failure points where we learn fastest so long as we try to stop the same problem happening twice, often by improving the communication to certain stakeholders.

And the stakeholders are who…?

I see them as anyone who has an interest or is impacted by any work your product team does. This includes investors, managers, client facing and technical support staff, other teams in your organisation, and of course UX, marketing and the tech team.

Each of these has a different perspective so they will each need differing forms of communication. The key here is to push out information and elicit feedback to understand exactly what they need and adjust the content or quantity of the communication. Just don’t expect them to give you a clear list of what to do.

How to handle team members

This deserves mention, because this relationship is about more than peer to peer communication. Managing people is worth a book in itself, and there are plenty out there, so I’m just focussing on what I see essential as a PM.

Clear communication and boundaries

People need to know what’s expected of them and what is acceptable and unacceptable. Boundaries don’t mean being dictatorial, but rather that any actions outside the boundaries need to be discussed clearly and agreement needs to be reached.

Show interest

Show genuine interest in your team as people demonstrates to them that they matter. This doesn’t mean you need to know about their private lives, but get an understanding of how they function, how they are motivated, what they struggle with.

In my experience it is possible to force someone to do something against their natural abilities and motivations, but that consumes valuable energy all round. It’s better instead to work with their natural inclinations and play to strengths rather than attempting to override perceived weaknesses.

Check in regularly

I know that personally I’ve been guilty of assigning work to developers and disappearing off into my own bubble while they work away in theirs. Checking in regularly shows regular interest, improves mutual understanding, and most importantly keeps everyone engaged in the outcomes they are aiming for.

Daily standups help to keep the team working together, but sometimes a deeper dive is required to get to the crux of problems that emerge. Again, this is an opportunity to reinforce the relationship and build stronger understanding. It doesn’t even have to be long, a ten minute breakout session can achieve a lot.

What about communication?

Communication has been mentioned quite a few times here as being essential to maintaining good relationships with others. The importance of communication and the multitude of ways it can be done is worth a post in itself.

Relationships matter

In writing this, it became clearer to me that managing relationships with people are more important than ever. On reflection, I was initially attracted to tech because I thought I could work in an abstract bubble and occasionally speak to someone as and when I felt like it. I know that just doesn’t happen in the real world, and I was a bit slow on the uptake.

Times have changed and tech is now necessarily much more human-centric as it continues to pervade our lives. I’ve changed too as I realised that being interdependent on others is also much more fulfilling, as ultimately it’s possible to get more done and achieve better outcomes by pulling people together and enabling them to do their best work.

I’ve been trying to being to improve my Angular skills and build a simple Kanban data visualiser in the process. I did this because I could see there are several Kanban-style solutions out there and most of those are related to task management.

Kanban has become widely accepted as a way to share the status of tasks thanks to its simple and effective visual impact. It turns out that Kanban is indeed a useful way to visualise and manipulate information. For example, if I have a bunch of tasks that each have a status and a priority, the standard Kanban model will allow me to move tasks through statuses “To Do”, “Doing” and “Done”. What I can’t do is juggle the priorities quite so easily unless I edit each individual card. So why not let me view my Kanban board by priority and move tasks around by priority too?

Airtable have clearly realised this and offer a Kanban view along with a grid, calendar and gallery (image-based) view so my thinking is not entirely original. With this in mind, I’m just trying to experiment and see if I can build a lightweight client-heavy visualisation tool to do this.

Kanban works, some of the time

It takes longer than you think so nothing new there.

Only certain data works in kanban format. Really, this means data where categorisation is obvious, such as items with priorities or statuses attached. On any particular set of data there may be only one or two candidates for sensible kanban-isation, and sometimes none at all.

Kanban is not just for task organisation. As it becomes a more familiar way to organise data, it makes sense to also use it as a way to be able to slice and dice data. Spreadsheet-style grids have become ubiquitous, because they afford easy recognition, although sometimes this comes at the expense of being quite cumbersome for the data concerned.

Kanban alone is not enough, unfortunately. Airtable realised this too (except they actually started with a grid). Calendars, image galleries, grids  and lists are all useful ways to look at data and Airtable have decent implementations of each of those.

Whether to continue or not

I’m not sure if there is any commercial value in this. There are plenty of similar offerings out there if you are willing to put some effort into structuring your data. Personally, I’m a little overwhelmed by the options, but you can check out my app on GitHub (live demo pending).

In my experience, people want solutions to their specific problems. They don’t want to have to learn something new unless they really have to. If they are using a spreadsheet and they are struggling, it has to get really bad before they make the jump. The risk and cognitive load involved in learning new paradigms makes this understandable. This means that using Kanban as a way to slice and dice and reorganise data has some barriers to widespread adoption in the near term.

After all, it did take a few decades for the Kanban concept to make its way from Toyota’s factory floors to the whiteboards and desktops of the tech world. For task organisation it now needs little explanation. For the purpose of organising more varied data, where I believe there is potential, it may take more time and clearer explanations than what I am able to provide here.

A short while ago I quit my job with no place to go. Superficially, an irrational decision as everything was going fine. I was well compensated and regarded, but I just couldn’t quite settle.

Getting uncomfortable

Being a little uncomfortable can be a good thing. It means living outside the comfort zone enough to grow personally and “being comfortable with being uncomfortable”, which I’ve often heard thrown around. Instead, I’m talking about being unsettled in a way that eats away at the core of your being very slowly. It’s a sense of no longer being on the right path. Your path and that of your company and career have deviated sufficiently that it’s no longer possible to keep the two together and stay moderately sane.

It’s a little like how the direction that a compass points, magnetic north, and true north are very close but not quite the same. Where I live they are just a couple of degrees out, which is not much. Follow one or the other on a compass for a couple of kilometres and this will make just a little difference to your navigation, which you can easily correct. Keep going for much further though and it gets harder to bring yourself back in line without a significant re-evaluation of where you are at.

Letting go

I see navigational errors have parallels with being in a job for a long time. You can spend 2 or 3 years where your values roughly align and there is mutual benefit to employer and employee in taking a role before moving on. 5 years of this and you need to quiet closely aligned. Any longer, like I did, and you really have to surrender yourself to the company way or be the person setting direction. I was doing a bit of both, but not really enough of either to feel settled, and ultimately I had to let go.

Correcting the course

Now, with the tension released, and a couple of months behind me to reflect, I realise it was the right thing. It was right to let go for a while and reorientate myself. Rather than leaping from one long term relationship to another, and taking some of the issues I’d developed, a healthy break is helping to evaluate what I would do better next time around.

I wouldn’t actually suggest deliberately taking a break if you are regularly changing job or you have commitments that a lack of income won’t meet. Chances are though, if you’ve been with an employer for 10 or more years that you have built in a bit of a safety net and the time, pace and distance gained may be therapeutic. Of course, no one can decide this except you alone.

3 things about prioritisation and decision making

I often find prioritisation hard. Much is written on this and there are plenty of hacks and tactics available. This is what works for me.

Is this the most important thing to start working on now? What else could I do? Ooh, what’s the population of Estonia? And the Baltic Sea temperature in April. Yeah, it’s a mess in there. In my head.

Inspiration doesn’t come from looking at a screen

I stare at my laptop looking for prioritisation, hoping that all the cogs in my life will start working together if I just find out this or that. When I start thinking like that, I’m lost. I start hunting around, get little done, and feel even more lost.

Focus on one thing and get it done

Just get on with it, step back, reflect. It’s when I’m not staring at the laptop that some of the magic occurs. Writing thoughts down on paper, on sticky notes and most importantly, forging direction are not things that you can do with endless browsing, hoping that inspiration will land.

Retreat, reflect and re-focus

Good, on the spot, intuitive decision making only comes about when the same or similar situation has been experienced many times before. That’s how pilots and surgeons survive. They’ve experienced enough similar situations before to know what to do with thinking to hard about out.

This is why agile software development works for me. The think, act, reflect cycle is more in tune with the way the human mind is architected. We’re not designed to make good decisions in the moment surrounded by lots of unfamiliar information.

For the rest of us trying to figure out where to go, we are better trying to make a decision away from the situation. So dust off your sticky notes, sharpen your pencil, make a mess and then focus.

I’m still struggling and continually learning as I go, but it’s getting better.

I’ve spent the last two and a half years of my life developing an online product only to stop and ask myself if this really is a product? It looks like a product, feels like a product, smells like a product, yet people are buying ready-rolled solutions built on the “product”.

The product in question is a collaborative spreadsheet-like database. People can roll their own datasets and share them around and get priced according to people and data usage. All good, except we never made it clear what the pricing was up front. What we ended up doing was giving people what they wanted, which was a ready-rolled solution.

Let’s build a product

The story goes like this. Someone has a problem, they look for a solution to the problem. You fix it, they are happy, you get paid, you are happy. Each time we work with someone we tweak things a it to give them a customised experience and this just adds to the non-product experience. The client gets their solution, they don’t really care about your product. In fact if they did, they would have been shopping around for something and comparing similar offerings, comparing features and prices.

The truth is they weren’t shopping around for a collaborative database solution. They wanted a decent solution provider and they wanted the solution at a palatable price. They also wanted something that just works.

Busy people need solutions

Moreover, the clients we serve typically belong to large organisations and need a solution quickly. This is where the standard product pricing strategy starts to fall apart. They just want something that will at least cost less than it would for them to do it themselves. They also want something significantly better and delivered quicker than they could do it themselves.

This is just the way people are. If you feel you can make the same thing yourself, you will probably have a go, just for the satisfaction of having done it yourself and it’s often referred to as Not Invented Here Syndrome.

Is it a platform? Is it a product?

Well, what’s gone wrong here. Nothing really, just the discovery that platforms are very powerful ways of creating growth. You control the information gateway and connect people together, even when it’s a carefully controlled deployment of the type that the information security zealots at corporates rightfully demand.

Once clients are with you, sheer inertia will often prevent them going elsewhere so you can continue to control how they get data in and out. As long as the cost to them of moving and is more than what you charge them, they’re unlikely to stray. And it’s quite likely that the difference in cost of staying is less, so unless there are other political machinations, no one is going very far too soon.

Platforms need a hook to get things on board

So why don’t we all just build platforms? The reality is you need a hook. Nobody wants to use their imagination to figure out how your platform could work for them. They want a drill to make a hole, not a rotary motor to which you can attach a drill bit. That’s why showing them a drill, but one you can make cheaply because you’ve made several similar power tools before, is a way to win business. Black & Decker [citation] discovered this many years ago. The Power of Product Platforms by Alvin P. Leonard and Marc H. Meyer.

A platform is a stronger hook

Building a good product is great. You get to build something that has the ability to reach and engage with the many. Building a platform is also rewarding as you get to reach perhaps slightly fewer, but you do get to fulfil people’s needs. Of the two the platform has the stronger hook and, you would hope, stronger revenue potential into the future.

I’ve been thinking about how to combine the intuitive feeling side with the logical process-orientated side. Anyone who wants to achieve anything inspiring will have to deal with both at some point and manage the internal conflict that emerges from the two sides.

Intuition and logic

For example, I know I want to get fitter and I know that will have benefits. My intuition tells me that to achieve this I’ll need to go to the gym, run, swim, cycle, whichever is my preferred method. The intuition telling me to do that is a feeling in a sense and it’s worth listening to. Unfortunately, feeling hungry, a bit tired, or just not quite up to it are also feelings that tell me I can get short-term satisfaction by listening to them.

Apes, lizards, jellyfish

There are several psychological models out there that talk about this as parent vs child, ape-brain vs lizard brain or even jellyfish-lizard-mouse brain.

but they all essentially mean that we are conflicted internally as we try to wrestle short-term comfort with longer term goals. There is also plenty of advice to plan your way to the goal in manageable, bite-size amounts, just get started and so on.

It doesn’t hurt to have a process

Increasingly, I’m finding that having a process helps no matter how small. Small processes mean that no time needs to be wasted in thinking how. Instead it’s more “I’ll try this and improve my approach as necessary”. The key is that the only commitment is to carry out a small process and reflect on it briefly. There are no major plans to follow through with or long term goals, just a few repeatable steps that, trust me, will become easier with time.

And how to know which process to start with? Just listen to your gut instinct and then commit to some micro-steps. Then use the logical side to analyse and refine and do things a little bit better next time.

So, how do you listen to your gut effectively? Well, that’s another story entirely.

I was always a little dismayed at the business world’s frequent mention of “Give me solutions not problems”. To me, this always felt a little off or missing the point, but in my less experienced days I could never figure out why.

Clearly, getting things done and fulfilling needs is a good thing, so how exactly does delivering solutions become a bad thing? Well, if I have a squeaky door and I lubricate it, the squeaking stops. A simple solution to a symptom to a problem.

If I find other squeaky objects, such as an office chair that grinds and squeaks every time I move, then I could perhaps lubricate the back fixing. Again, a trivial solution to an apparent problem.

Treating symptoms as they appear

In both of those examples, what I am really doing is just treating symptoms as they appear. I have a tool, the lubricant, and with it I can go looking for problems, or rather symptoms, to underlying problems and deal with them. And then, I can call myself the man who sorts stuff out for you.

In the tech world, the solutions can be complex to complement the inevitable multitude of interwoven problems. Even in these cases, however, there is often a single fundamental “why?” driving the action. Why are we trying to fix this? Why do we need to solve this problem?

The solutions that match specific issues are often good for that specific moment and set of circumstances, but in a complex environment any of those may change at any time. The result of this is that we soon end up with a slightly redundant solution. With time the underlying requirements shift and more solutions may get added so we end up with a patchwork of solutions no longer quite fit for purpose.

So how do we deal with this creeping, solution-invoked redundancy?

Requirements masquerading as solutions

One way is to be aware of requirements presented as solutions. “I need you to do x because of y”. Instead, try to get it expressed as “I have this problem and I need to overcome it”. This immediately opens up everyone’s thinking to possibilities.

In the case of the door perhaps we can get some maintenance guy to check it every month and lubricate it so I don’t have to put up with the squeaking? Or maybe we get him to re-hang the door on its hinges as it never really swung freely and that was the underlying cause of the irritating noise? Actually, do we need the door at all? It would, after all, be one less thing to worry about at the expense of the real work that needs to be done.

Discover the problem in the simplest possible terms

Getting the problem defined in the simplest and clearest terms possible will help find the most elegant solution. This is how we discover a fundamental need. Once that need is understood it can be addressed and often we might find that it leads to a better, happier result all round.

So, perhaps removing that door would open up your space a little more, creating a peaceful and airy environment, which is actually what you truly desired all along.