Atlassian Documentation for Product Design Teams Part 3

“Transparency is the new objectivity.” — David Weinberger

In this latest article, we look at the structure that increases the transparency across the product team. There is a no better place than the business section represented by three subsections––Hello, Business and Research.

1.0 — DaS Hello

Let’s start with a short story. We often see new team members arrive — they don’t know what to do, whom to talk to or how to set themselves up. They start asking too many so-called apparent questions. Entire departments HR specialists start walking around in circles instead of focusing on what is necessary–the product.

This section elevates the challenges around new arrivals and how we integrate them with an existing team. An Overview page summarises the project from a non-business perspective. The onboarding section helps the new member to find out helpful information to get started. This reduces mistakes and builds better bridges between different team members. Whereabouts support all team members in their way and come as very useful not just in the beginning but also through the process of transition.

Equally, it allows anyone to stay on top with new passwords, general info and updates across the product / if not a company or department. Interactive org charts and a people accountability matrix are not exceptions. A complete library of your engagement insides, including the strategy and how to run standups and other product-related ceremonies. Information about the software park has been one of the most visited, according to analytics. One of the best things for the big organisation’s project was the team page, including the team information responsibility and contacts.

The whole setup is a 20+ page list. The benefits of gradual introduction are much smoother and less pressure on the team. Only three groups in my 14-years practice asked me for a complete structure upfront as they wanted to know what they are missing and what they need to work towards. I’ve hurt saying “too many empty pages” (link to the following paragraph), which did not initiate the interest of defining them or discussing why we need such page.

2.0 — DaS Business

Unless your product is super-secret, this section is a general gateway for anyone who wishes to understand the product and its status. The most visited page is the Road Map. When done correctly, it can be integrated throughout the entire proposition and help you see a comprehensive picture.

This is not too common for Agile practice (as this is an entirely different method); several businesses adopted PID–Project Identification Document. This page summarises the proposition in a specific form. Very practical, especially if you find yourself dealing with a more complex product. A combination of both can bring insights that help the team reduce complexity and clearly communicate the dependencies (in the form of HTML links). The PID is followed by OKRs and ROI metrics. As these tables generally can be pretty complicated, business people tend to upload them anyway. One product owner surprised me and simplified them specifically for the Confluence page and for his team. The applause he received in the following stand-up was hilarious and showed the unity of the group. He was later rewarded with a stable product that was launched three weeks before the 12 sprint death-line.

Some CSM?/CPO? oversee this section creation as they constantly deal with unblocking things for the team. One CSM? has created JIRA tasks for himself and listed them on a separate page. A clever way of tracking time (that’s perhaps for another time). Teams who link both JIRA and Confluence together saw tremendous benefits. Some of the bold and transparent product owners gained massive respect and significant contribution from the team despite those who kept their communication problems hidden from the business.

Essential learning came from an educational team building a behavioural science proposition that I was working with. Working under pressure and facing constant change and short deadline, this section became a hub for all the changes and definitions. The framework proved itself in terms of collaboration. All parties involved, management, design, education specialists, and developers, agreed on the impact on their day-to-day work. Unfortunately, what didn’t work was the business appreciation of product design development. The pressure of the Beta release date impacted the transparency, which eventually leads to inefficiency and mistakes. A demoralised and disorganised team could not perform their best, and the decision was to postpone the launch altogether.

3.0 — DaS Research

When it comes to whether research is important for a product, I hate to say “it depends”, but it really does. Suppose you are a start-up of three and do not have the research resources — if so, then skip this section entirely. If you plan to grow to 20+ people product team this year, this section is for you. Whether you’ve got access to a User Researcher or not, you’ll need to do your diligence and perform market research, looking at trends and user behaviour. This means you have to collect and describe what, why and how the following impacts your proposition.

In the agency world where pitch decks are still being used, showing the inspiration and strategising is impossible. This beautiful PDF presentation will be hard to find on the server in a month’s time. Sadly, no one remembers what colour has been proposed to the client.

Thankfully, this section allows you to not only standardise your research but have an imminent impact on your product. Working closely with four fantastic research teams across education, media, retail, and especially finance, we have distilled the ultimate must-have for any product team.

Starting with a Competitive and Market Analysis that takes in behaviour and style, this space is an ultimate product fit knowledge base. Understanding where we have come from, how we research and test propositions, and how we need to fit the market.

It’s not what we have found or researched, but instead what impact the findings have on our product. The majority of the analysis stays in PDF, keynotes, PPTs format and after the first (last) presentation, no one can really find them. Design at Scale ensures that the research is a vital part of the delivery and, with testing, new research happens which influences and enhances the existing product. By including these insights into product development help researchers to collect, organise and present their findings. First, it helped us validate correctly throughout the project’s entire length- what we set out to do. Secondly, the enhanced knowledge from the beginning helps us learn new things and improve the current release.

The value of this well-integrated knowledge base is a validation of all your real-world assumptions.

The section is divided into five subsections: Insights, Competitive analysis, User Research, Behaviour Models, Tech. Analysis. All these provide an initial starting point for each discipline to articulate their point on approaching development.

Common Questions

What mostly failed

Suppose the team doesn’t understand the benefits of centralised communication?

In that case, they’ll waste time in silo discussions, complain behind colleagues’ backs and indulge in endless email games resending definitions between various parties. In this case, it will be challenging to prove that any method (even this one) works, to be honest, as there is no baseline. The learning–it’s not the diversity of the tools you are after, but the mastery that goes in them.

Slack and other tools.

This might not be a popular view, but personally, I haven’t seen any Slack integration that really helped the product team work better or wiser.

The Slack discussions usually get significantly separated. Take a 12-person start-up that I recently work with. It was spread across three continents, with three different working styles that incorporate the latest tool chain-Slack, Miro, Google Meet. Slack ruled over all the discussions, document handovers, updates, meetings, decisions, asset delivery and change requests, passwords issues and so on. We soon realised that the number of changes and complexity killed our momentum. We did not know what has been delivered and to whom. The contributors start replying on different channels. The assets management has no versioning, while compressed versions affected the final product’s quality as everything is pixelated. Whenever I attempted to organise this team, we ended up in more significant discussion and created yet another Google Sheet.

Unlike the previous spread-sheet reflecting neither the epic, story or task discussed in sprint planning the week before. No surprise that this team did not launch anything in 10 months of its existence. Consider the tools and the time you invest in them. We all employ cheaper tools to get more effective and not see how valuable time being burn in them.

Too many empty pages.

A colleague called Josh from SGI once said,

“My friend, if you require all the final information for your work, you might give up to work entirely. The only certainty in this world is that everything is in constant change.”

— Josh F. SGI 2002

Instead of investing time in silo discussion over WhatsApp or Slack, we can support the same amount of time defining what we are after. Spending time on the definition creates undefined opportunities:

• Developers can start commenting on the proposition and its feasibility.
• The business representative can comment and validate the page for the Alpha or Beta release.
• CSM? can link to the JIRA User Story relates to your thought, so we can discuss it at the next Sprint planning.
• Meanwhile, SA can connect to the previous test in the BitBucket–and so on.
• not even mention happy designer creating their maps, diagrams and graphics from something that has been thought through.

Negative chatter ultimately generates flattery for a moment, but the grand scheme reveals the misery of our days behind the computer. As all of us burn valuable time, and nothing gets done, we generate even more frustration and resentment in this overwhelmed situation.

Next time you attempt to write something in Slack, Teams or over email, ask yourself the following question,

“How do I contribute to building the next best digital product by communicating this message at this very moment?”

There are literally hundreds of stories like that where people with real focus and determination make things happen where the others just live out of the chatter. I hope you enjoyed the third part of this story. I’ll look forward to welcoming you in a week’s time to see how this all continues.

Stay tuned; thanks for reading! Thanks to all contributor especially Matt Press, for their insight and comments shaping this very article. More recent articles are available at givetm.medium.com/

Jiri Mocicka is a London-based designer writing about his passion for the Design at Scale–integration and design operations that builds excellent digital products.