An Ode to Product Mindset and Developers Who Know How to Ride a Bike

Companies mostly work “in projects” these days. It’s basically a shortcut for a team of people focused on a shared goal for some specific time. We are used to terms like “project success” or “project management”. No wonder people care about their projects and everything that comes with it - success or failure, deadlines and tasks. This is what the days consist of - projects. Ideally, from time to time, we take a deep breath and go through the whole system, thinking how our current task fits in the context. Thinking about the product. Sometimes though, we might lose ourselves in the day to day work, focusing on delivering a project and forgetting why exactly we have this whole thing going on. And it would be just such a shame - developers are much more than just highly skilled workers, they are creators. We just sometimes forget about it.

The Jira trap

I already expressed my (complicated) love for Jira before. Using issue tracking tools can make your everyday life easier and more manageable. I would never advocate not using one. But… Jira is exactly this - a task focused tool. It enables breaking the big requirements down into epics, then user stories, then tasks or even subtasks. In essence, this is a trusted method of decomposing a bigger problem into smaller ones. More atomic issues are easier to control and deliver. Seems like a reasonable thing to do. As long as you keep in mind that the small issue is a part of a bigger whole and this wholeness is what you are all after. That’s when Jira’s ability to decompose comes as a double edged sword. As much as it supports a top-down planning, it’s not just as easy to build the bigger picture bottom-up again. How often do you actually read an epic? Or even use one? Maybe no one was reading it anyway and you all decided to skip them? Because the road from a task concerning a change in an endpoint - to the epic about making reservations in a system sometimes seems so long, that many people might not feel like walking it more than once. But agile revision of the backlog does not only concern the development tasks - even more importantly, it requires reflection on epics and user stories as well.

Creating software

The focus on small steps is totally fine at the beginning of your career. It’s the same as learning how to ride a bike. You focus on small elements first, which pedal to push now or how to turn with the handlebar. Then you concentrate on the fact of riding itself and not falling down (too often). But after a while, you are able to choose a road and destination, focus on where you are getting to and maybe also enjoy the views. That’s what happens when you lift your head from the code and try to see what’s around you, what is the reason behind writing this specific piece of code. If you do that, you might actually have a say about where you are going to and which road to choose. Agile approach expects you to do it more often, one time analysis at the beginning of the project will not be enough. Check the road you’re on frequently and adjust it if necessary. Without a perspective and context, it’s hard to have a sense of direction. If you try making agile-like changes with a waterfall mindset you can end up in a state of child-like confusion. It’s a trap both for developers and managing figures - a whirlwind of acceptance criteria, statuses and looming deadlines can suck in everyone equally.

What a user wants, what a user needs

By definition, understanding a user’s needs is a domain of someone in the project who identifies the requirements and manages the product backlog. It’s great to have someone dedicated just for getting these right. But it’s not enough. It’s one of the reasons behind the agile manifesto - the necessity to understand the user’s needs by the whole team. The simple fact is that it is not possible to make a good product without understanding what it’s for. But funnily enough, it is possible to write good code without such understanding. A beautiful, clean code. Just… with no real purpose. As much as the code quality is very important, it will be just a buried piece of gold if no one wants to use it. No matter how tasty the wedding cake if you decide to deliver it at the funeral.

It’s important to aim at being a good developer and to improve the quality of your code. But choosing the right solutions based on the product’s and user’s needs is where being great begins.

Delivering products, not projects

When a client approaches us, she or him rarely asks us to deliver a project. What a client is interested in is the product and its value. The artifacts of a project - a task board, burndown charts, meeting notes are there to support us on the road to the actual product. If a Sprint review meeting ends up being a presentation of the issue progress on the board accompanied by some charts, it only shows a project progress. What is really of value is the system itself - what features are done in this particular version? How do they work? No matter how many tasks have been moved to Done, in the end the increment should bring the expected value and the client should be able to verify it somehow. A system that’s just a pile of unconnected screens and functionalities, even prettiest and cleanest ones, presents very little or no value at all.

Bring the spark back

Let me bring up one more thing to the table. The actual pleasure and excitement that comes from creating something. Not just a button or an endpoint, but a whole solution, as a team. You don’t need to carve in wood or stone to be considered a creator - you create systems. I think it’s easy to forget between one git push and another that writing software is really an art of creation. There was nothing, emptiness of dev/null and then, line by line, something appears and works, is used by actual people who potentially find it helpful or fun. Moving tasks to Done, ticking them one by one is as satisfying as any To Do list but seeing the bigger picture and how the button you added actually works for people - that can be really fulfilling. You just need to lift your eyes from the handlebar, as soon as you’re ready. Look mum, no hands!

Before you set off for the adventure

As much as with biking the progress from unsteady pedalling to smooth journeys happens pretty fast and is easily noticeable, it can be more tricky when it comes to software development. It may take years and be more gradual. So how do you know whether you’re really lifting your head from the code? You may ask yourself a few simple questions

1. Do I know the actual use case for the piece of code I’m working on right now? What’s the main business value to the client here?
2. Do I know what my team mates are currently working on?
3. How do I react when a pivot in a newly introduced feature is needed? Can I embrace the change coming after client's feedback? 
4. What would I do if I felt that the acceptance criteria in my task are lacking or not aligned with other parts of the system? Would I notice this? Would I propose a solution to deliver the feature or follow acceptance criteria to be done with my task?

Every project is different and of course the business perspective is not always accessible to the developers (or in fact project managers as well). However, your mindset is your own personal power and asset. Building a product focused attitude is a great value that will stay with you longer than your current project.

Where to go next

If you're still unsure about the whole product mindset thing or you'd like to dig deeper into the subject, I prepared a small and subjective list of some interesting and fun sources:

• A straightforward summary of the topic in this Your Daily Scrum podcast episode
• A comprehensive overview of the organisations transformation from project mindset to the more product focused one in "Project to Product" by Mik Kersten (or start with one of his public speeches, like this one
• Fascinating insight into users’ perspective and motivations in "User Friendly" by Cliff Kuang & Robert Fabricant or in "The Design of Everyday Things" by Don Norman 
• An interesting concept of product engineers - developers with a great product thinking in a video by Sherif Mansour
• For exploring mechanisms behind successful product management - "Product Leadership" by Richard Banfield, Martin Eriksson & Nate Walkingshaw
• Bonus source - Kent Beck’s newsletter with lots of code related ideas, but his main goal now is to “Help Geeks Feel Safe In The World” so plenty of soft skills and product related content as well.

It's all just Agile in the end :)

Listen to BrightDevTalks podcast on Spotify. Kasia and Ula from Bright Inventions take cycling to the next level. Podcast is recorded in Polish.