1. Good team health = successful products

Speaker: Lara Hogan (She also has a nifty book out on Resilient Management)

Bruce Tuckman’s Stages of Team Health.

6 core needs at work: (BICEPS).

1. Belonging.
2. Improvement/Progress.
3. Choice (in balance, not too much!)
4. Equality.
5. Predictability (again, in balance, not too much!)
6. Significance.

Feedback.

Being factual and non-judgemental is key, understand what they care about and being clear about purpose.

The feedback equation: Observation of a behaviour + Impact of behaviour + Open question: “What are you optimising for?”

Team Processes.

• Regular retrospectives.
• Living team charters and docs.
• Clear roles, including knowing what responsibilities are shared vs owned.

2. From design Systems to decision Systems

Speaker: Kim Goodwin, also here’s another good talk from her on human-centred design.

Decisions create the user experience.

the revenue model often being the biggest component in decision systems.

Consequences of these decisions have impacts on opportunities, society and mental health.

Product decisions create the “HUMAN” experience.

Using data as example: our methods of design were based on a time where data meant something different;

1990 = Manually enter data, products built to complete tasks

VS

2019 = Data collected and combined by products to influence human behaviour

• What uses of data are acceptable?
• When is it OK to influence behaviour?

Design is not inherently human-centred.

Creating human-centred values using the Nuremberg code set of ethics

• Is it of benefit? To the user? To society?
• Is it the only way?
• Risk proportional to benefit?
• What harm is possible?
• How will you minimise harm?

Good decisions come from diverse teams and good tools.

ie: why did every fitness tracker take literal years to add in period tracking to their products?

“We cannot imagine the types of harm we have never seen or heard about”

Tools:

• Be data informed by metrics and measuring at least 2 things.
• Find focus by determining the Goal vs the Values you won’t sacrifice to get there.
• Talk to humans! (User testing)

If you don’t apply it when it’s inconvenient, it’s not a value

Importance of component libraries.

Look at how you would do this for different teams? Invest at least as much inthe decision system as the design system.

3. Adaptive content: Supporting Content across multiple device types

Speaker: Karen McGrane, has books out!

How physical printing still constrains our thinking on how we publish content.

History of Publishing: Print > Web > Mobile > Tablet

The same content can now sit on multiple mediums including:

• Wearables.
• Gaming Systems.
• Smart TVs.
• In-Car.
• Smart Speakers (Audio).
• Digital signage.
• IOT — appliances.

This links into optimising content for accessibility — simple additions to websites like using alt-tags that help screen readers for vision-impaired, also help services like Alexa or Siri find more accurate answers to things.

How do we ensure that we adapt our content for emerging technologies?(Creating content that is fluid and available for reuse)

• Separating content from presentation — content that isn’t locked to a single style or medium.
• Where possible use chunks of content over large blobs of content.
• Invest in semantic metadata, and ways to structure your content more effectively.

4. Engaging in disability as a creative practice

Speaker: Liz Jackson — her website!

Discussed designing with disability, not for disability, and including/acknowledging those with disability and the work already done.

Empathy — moving from inspiration to pity.

1. reifies the power structures.
2. prescribes emotions.
3. silences the recipient.

Example: Lego braille bricks, made for the visually impaired, awesome idea and intention, however when it came to the marketing it was released as a video. Cue feeling exploited and left out of the conversation.

Disability as a designer — the ultimate (and original) life hacker!

This is to override the pervasive narrative that disabled people are recipients rather than the drivers of design.

Design Questioning over Design Thinking.

Honour the friction of disability.

Disability wasn’t a ‘thing’ until the Industrialisation era, because they could not contribute in the way that society wanted them to.

Not all things need fixing, they just need to exist.

5. The joy and weight of responsibility in our working lives

Speaker: Courtney Johnston: Director of Audience & Insight at Te Papa

The voices we give power to are the voices we hear

Discussed the role of museums in the world today — and the flawed assumption that museums are inherently objective and how often well meaning intentions create more labour for those it is trying to support.

Example of how patronage within the art community influences the decisions and opportunities that are available.

Highlighted the balance of:

Sustainability of the organisation VS Ethical sustainability.

Courtney’s full transcript of her talk can be found here, (CW: suicide).

6. I still believe in heroes — Fandom on the Internet

Speaker: Sacha Judd — slides here

Using the examples of Marvel fans to explore the idea that in the Internet there is no such thing as a neutral space.

Transformative Fandom vs Curatorial Fandom.

• Transformative fandom: Allows fans to create the reality they want to see, often to ‘fill in the cracks’.

Fanfiction is a way of the culture repairing the damage done in a system where contemporary myths are owned by corporations instead of owned by the folk. — Henry Jenkins (1997)

• Curatorial fandom: these fans know the ‘facts’ and all the things about their passion.

With new adaptations of movies for example, the friction comes most commonly from the curatorial fans, as this challenges their ideas of how something ‘should be’, the change is seen as a threat to that.

Pop culture IS political.

There is no way to create content without it being influenced by the current socio-political environment.

The platform vs publisher argument.

• Prioritising revenue over impact.
• The myth of neutrality in the Internet: in large open spaces like Facebook, to small communities like Slack.
• Amplification of content outside of it’s intended audience.
• Deplatforming works.

To be the heroes we need in the world:

1. We need to weild the power we have; where we spend our money, and collective action where we work.
2. More diversity in the room.
3. More regulation.
4. We need companies with values.
5. We need to build for the future.

If you can’t define what you stand for, your profit will

The Ethical OS Toolkit:

A guide to anticipating the future impact of today’s technology — Or how to not regret the things you build.
https://ethicalos.org/

Caveat: definitely some much better detailed notes can be found here, and previous year’s talks here.

As I adjust to my role as Product Manager, I’m learning a bunch of things about product work. I’ve read a lot, watched the videos and taken online courses about being a good PM. In theory, I have set myself up well with a practical base as to what you should do.

But what these resources can’t teach you is how to translate that best practice knowledge to the specifics of your own environment, and how to approach working with people who have different perspectives than your own.

When we were deciding on what processes to use in our product team here at Figure.NZ, we considered some things that make us who we are. We’re a non profit and in the past we’ve operated on a limited budget. We’re a small team and remote first. And these are all factors I consider when prioritising, estimating the complexity of a job and knowing who to call on to help.

4 things that helped me set up process to benefit us in the long run

1. Setting your product direction

At Figure.NZ we have two big organisational goals, and our product direction is designed to hit those goals. In the absence of overarching goals you could also use themes to drive your product direction. We previously used themes to prioritise the mountain of backlog we had accumulated while we were in startup land. Now, with regular funding we are able to think differently about where we put money and resource.

It’s important that you, as the PM, know the product direction like the back of your hand, and it’s also crucial to be transparent about it with your team.

Ask yourself some questions:

Q: As an organisation what are we ultimately trying to do? A: In our case it’s get people in New Zealand using numbers in their thinking.

Q: What parts do our products play in this? A: Our website is the one place that aims to hold all of New Zealand’s public data.

Q: How could our organisational goals translate into product work? A: Improve the search function on the website to help people easily find and access these numbers.

Q: How will you determine when it’s successful? A: When the number of searches resulting in ‘no available content’ has decreased.

Examples of themes could be:

• Strengthening your foundation: working on the infrastructure of your product to ensure it can withstand increasing load, or update with latest software.
• Improve accessibility of our product: can anyone use your product? Think about disability, language barriers, access to limited internet and limited internet speeds, offline/online usage, machine readable …
• Go above and beyond: features that can increase usage, support or provide delight.

This is how we set our product direction:

Gather org goals > translate what these mean for the product > determine what objectives are required to get there (using current knowledge, and knowing these can change as you figure out more) > How will you measure these? > What individual tasks are required to achieve the objective? (These tasks will show up again in your product plan).

2. Create a product plan *cough* roadmap

The product plan is how you think you’ll achieve the goals set out in the product direction.

It’s like a roadmap. Actually, it is a roadmap, but I don’t like that word because traditionally, a roadmap is seen as a set-in-stone doc that promises what will be achieved in the next 12–18 months.

You’ll need to give notice if something has become more complex than first thought, or if you figure out that what was once a great idea, actually isn’t going to work and plans have changed. Convincing key stakeholders it’s a working document can be tricky, but working fluidly will save you money down the line, and this is your best argument for a flexible product plan. This article and this article have some great points that can help get buy-in from everyone.

Ask yourself some questions:

Q:Are there external, unavoidable deadlines or promises made to people outside the organisation to consider?

Q: Can you see any obvious pieces of work that would need to happen before others?

Q: How much money do you have and how is it allocated?

Q: Who is involved, and when? At what point should devs get involved? When should stakeholders review possible changes?

This is how we set our product plan:

At Figure.NZ our product plan is what we’re working on now, what’s coming up and what we think should happen after that. It doesn’t talk about why we are doing it, because that was already agreed on in the product direction.

The plan gives the wider team a heads up on when specific tasks will happen; but we’re empowered to change this as we get more information or context. We value efficiency so if there are things that make sense to work on at the same time because they, for example, touch the same piece of code, then we will switch up the order.

Being remote-first, I wrote our product plan up in a Slack post as a series of things that could be checked off. And when I update it, I make a comment on the post, which acts as a sort of commit (ya know, like Github, see I can be technical too). It gives a notification of the change, and also reappears in the Slack channel, giving others a chance to have a quick look and ask any questions. Click here to see my product plan Slack post template.

3. Give regular updates on product changes

This involves determining who your audience is and what is important for them to be across

For external release notes, involving your communications/marketing teams can be really important to help you share news of changes to the public.

Ask yourself some questions:

Q: Who needs to be informed and why is it important to them? Will these changes or updates affect other individuals or teams?

Q: What language will best suit? For example, people in sales might be interested in new features or security improvements versus adding a button to go back one page.

Q: What level of detail do I include? Do your team need to why you changed/added/fixed things?

This is how we give updates to the wider team:

At the beginning of each week I write a brief summary in Slack on what the product team has been working on, and include any changes made to the product from the previous week. One of our products is Grace, an internal-use only product, and it’s important that the data team is across any changes we make.

I try to limit technical jargon and keep the detail relatively low. The point is to highlight what we’ve been doing, why it could be important, and if it affects anyone in particular. Don’t assume people have the same technical knowledge as you or that they’re familiar with the product history.

Example of update:

End of week 11 August 2017:

• Fix to search, means users can now see X and Y when shown a result
• Enabled new chart type in Grace. Data team can now visually represent X data.
• Met with comms team about upcoming event Z, we have actions written down [link]

4. Have an accessible task board

Have a place where people can see what you’re working on! The aim isn’t to check up on what you’re doing, but to understand where things are at and minimise the amount of time I have to spend answering questions like “where is X at?”. We wanted to create a process that is lightweight but structured enough so we know what next steps to take. And it’s important to me that we have the freedom to use our initiative and not lose the magic that can happen in between.

This place can be a physical wall with post-it notes, or a platform for managing tasks like Trello, Asana, and ProdPad. There are tonnes more but these be my faves 💖.

Ask yourself some questions:

Q: What types of work do you do to your products? Are they bug fixes, improvements on existing function, new features, maintenance/operation?

Q: What are all the actions we go through from the beginning to the end of a piece of work?

This is how we approach a task board:

We use a Kanban style Trello board to manage our day to day work. We chose Trello as it’s remote friendly. Some of our principles are:

Anyone at Figure.NZ can read the cards on this board and see where we’re at.

Anyone is able to add ideas, feedback or pain points to the Inbox on our Trello board for the product manager to review.

The product manager is the only one who can move things from the inbox to our backlog, and who has the power to remove cards from the board. The PM will always talk to the person who created the card before removing anything.

Cards can go into a blocked column, which isn’t necessarily a bad thing, just an indication of where something is at and why.

To sum up or TL:DR 😪

Document a clear product direction for why you’re working on things, have a product plan and regularly give summaries of what you’ve achieved and how the changes could be important to others.

These actions allow your organisation to keep up to date with the product so they can provide feedback or ask questions before it becomes costly. These are processes that will ensure all teams within an organisation can do their best work.

If you wanna chat about this or related stuff let me know! I’m on Twitter :)

The product manager’s guide to new process was originally published in It Figures on Medium, where people are continuing the conversation by highlighting and responding to this story.

Leaving my hometown of Christchurch for Auckland in 2011 wasn’t nearly as intimidating as it would have been in the pre-earthquake world. I’d survived, and with this came a new awareness of the need to make the most of every opportunity. This pushed me to take bigger risks than before.

Since moving up, I have been part of 4 tech startups where the attitude is to just figure it out, try your best and get stuck in. You learn to be resourceful and snap up opportunities as you see them. Also, it’s up to you to do it — not someone else. You have to be a generalist. The definition of a generalist varies but, basically, it’s a person who is competent in several different fields or activities.

It took me awhile to learn to value my skills. This is because I thought if you didn’t specialise early in your career, you wouldn’t be able to get a good job later in life. Now, I realise I can specialise in being a generalist, and that this is a skill in itself (and a particularly valued skill in the startup community).

Figure.NZ is where I’ve been the longest, and as I approach four years here (that’s like 25 years in startup world), I’ve been doing some thinking.

I’ve witnessed Figure.NZ go from a startup to a successful and sustainable non-profit, but what is rarely discussed is the rollercoaster of feels you can go through when an organisation grows and you are in the position of generalist. You go from an environment where being able to do a bunch of things is essential — to a time where people who specialise are critical to move things forward. This can feel disheartening and discouraging, because a specialist hired for a particular role is likely to be better at that particular thing you used to do, as part of the 70,000 other things you did as part of your job.

As Figure.NZ developed and grew, the things I did on a daily basis slowly felt like they were being taken away from me. These were things I was part of creating and now they were being passed onto others. My babies! I started to think that perhaps there might come a time when I wasn’t needed, and that, I think, was my biggest fear — that I wouldn’t be required anymore.

Saying that, it was important for me to recognise that for a few things, this was a relief. One example of this was creating data content. When I came on board we would take the tables of data, tidy them up a bit in Excel so they were uniform and add the variables to a javascript template we had for each chart type. I would also do things like edit the title and labels.

We created these charts one by one, lovingly by hand, for others to use. But it would take me so incredibly long, and while I loved the bit where I could pretend I could write code, auditing the data was not my passion.

Then a development team called Opcode produced the very first version of Grace, after an all-day hackathon. This took out the need to use Excel or to understand the intricacies of javascript to display our content, and the chart creation process became a lot easier and faster.

Being part of building and testing the first version of Grace felt like we were moving forward. It became obvious though that we couldn’t create and audit content fast enough with all the other jobs we had on. So we hired Andrea, who would become our chief data officer. His knowledge of New Zealand’s public data and confidence in how to present it was seriously a blessing. Without him we would most definitely not have the tens of thousands of charts we have now. The efficiency of our data team is truly a beautiful thing.

So, what is the point here?

Well, I guess it’s important to remember that in any job, things will change, and should change! Without a generalist like me at Figure.NZ from the beginning, we wouldn’t have been able to grow it to where it is today. That isn’t me tooting my own horn by the way (best idiom ever), but I was in a position where I had knowledge of how previous startups had run, experience in digital media and a general passion for being helpful and learning. I knew how things could work and I got on with it. We had a shoestring budget at the beginning, and we worked within its confines to a point where we didn’t have to do that anymore. This was the goal within that environment.

5 things that helped me get to where I am today:

1. When you start to feel insecure about your position, paranoia can set in. Trust that it’s about working together for a common goal, not about fighting to get to the top.
2. Remember your value at work, the fear is real! It’s okay that sometimes you will need some reassurance.
3. Be realistic about what you can and can’t do well; and remember the importance of letting go of some things so you can get better at others.
4. Make a plan for the future. Where do you see yourself heading, what do you enjoy most? Having a plan for career development is important.
5. Appreciate the wisdom you get from new people and the lessons learnt along the way.

What am I doing now?

These days my job title is product manager for Figure.NZ. My knowledge of the products we have built, the goals we want to achieve, and the relationships we have with our community over time come in handy here. I use the experience gained from previous roles within the organisation to understand the perspectives and needs of those internally and externally.

The awesome thing now is that while I’m still a generalist, I have more time to gain a deeper understanding of product management — something I didn’t know I would love without first doing a whole bunch of different jobs. Success now, for me, is being able to dive into concepts and problems to find solutions that achieve our goals. I’m still doing a variety of different things, I’m still learning and I can also help out in most situations. I now specialise in being a generalist.

Last thing, it does depend on where you work

At Figure.NZ we recognise the value that each individual brings to the table. Each person’s unique experience and knowledge adds dimension to not just their particular role, but also to help shape the organisation as a whole. Having multiple skills and knowledge in a range of areas are prized attributes. Each of us contribute to other teams with our experience and knowledge, participating where appropriate.

What is also totally valid is making sure you’re doing what gives you job satisfaction. This might sound corny but what I mean is: if you love being there at the beginning of a startup to nurture it to a point where it appears to take off, then that’s okay too. There’s nothing wrong with wanting to move on.

So, to finish up, I don’t think there is a right or wrong way. There is only your way, and being a specialist or a generalist is not better than the other, just different.

Generally speaking… was originally published in It Figures on Medium, where people are continuing the conversation by highlighting and responding to this story.