I think are we good?
Okay, so next up we have some product management coverage content by Loria.
Hi.
Yeah, so I've been a little bit of an AV disaster, so I'm going to have to look at my slides
because I can't see them here.
But here's the title of my talk today.
My goal is to help you get more structure around your open source projects, hopefully
save time and ideally do less.
Okay, so about me, I'm an American living in Germany since 2015 and I mention this because
I came to Germany with a very live to work mindset and now I have a very work to live
mindset.
And you're going to see that mindset shift in my talks, like the messaging I share with
you.
Among my many open source activities has been contributing to Kubernetes, particularly
SIG release and also more recently the open SSS security scorecard project.
I have this link here where I thought I'd highlight it because you can find a lot of
management and leadership guidance there.
It's a collection of resources, blog posts, videos, templates, things like this, including
some things I'll show you today.
I've worked in places.
I'm not working now.
My company shut down at the turn of the year.
So if you like what I have to say and think I could be helpful to your organization, let's
talk and there's my LinkedIn in the meantime.
I'll cover basically two branches in this talk.
First is some observations from my time in open source.
I'll sprinkle some helpful hints and examples along the way and then I will focus on some
tried and true traditional product management methods that work in a company setting.
You've probably encountered them in your day jobs, but they also work in open source
with a little bit of creativity.
So some of those observations, I see contributors taking on so much work.
Just lots of issues, many times even multiple leadership roles and it just seems like a sure
far way to burn them.
Because they're so overstretched, they don't have a lot of time to do a lot of research
and gather data.
Also, that's a skill set that not everybody has and not everybody needs to have.
But the end result is often that a lot of development is based on assumptions instead
of data.
Another thing I've noticed is that what exists today in a project isn't well-defined or
documented or mutually understood by the project team.
This represents a pitfall because you maybe don't have the shared understanding of what
your project is and does and should be.
And lastly, there's often times of vague strategy or even none at all.
I would say that the most acute manifestation of this issue is that there's often a boundary
between what goes in a project and what stays out that is lacking.
This can lead to a lot of work being done and that work just kind of expanding.
So if you take away anything from me today, it would be this message which is I really
encourage and invite you to do less if you can.
I know your manager may not want you to do less.
There's always very specific conditions around that relationship, speaking from experience.
So I'm happy to talk to any of you after the talk if you would like to have a sound and
pour like ways you can manage your manager's expectations around what you can do in open
source with your limited time and availability.
But if you are the pressure source telling yourself to do all of the things, then I invite
you to ask yourself at first like, does anybody even want this?
I mean, maybe they do, but maybe if you're the only person or you don't have a very
clear sense of how many people might find value in your project, maybe stop and collect
more data before you move on.
Also keep your personal backlog light.
I know some people really enjoy working with them, but they take on so much work that they
end up becoming the blocker for other people to make progress.
And you don't really want to do that, right?
You don't want to impede your fellow project contributors' efforts because you're like
the decision maker on 10 different things.
So that leads to delegating.
Delegating not just to reduce your workload, but also to empower others to gain skills
that you have.
And I know that's rather time consuming, but oftentimes what I've seen in open source
is that a little bit of upfront onboarding and knowledge exchange saves everybody time
in the later stages because you have multiple people who can work on something at once.
And the last tip is something I've used over the years because I would just take on work
too.
I love it, like, let's be busy.
And then I would find that the work that I took on actually involved a lot more than
I bargained for.
So I highly encourage you to unpack a task before you say yes to doing that task because
you may find that it's going to take you a significant amount of time.
Here's an example of that.
So this is a project board that I created with collaborators from SIG Release and Kubernetes.
The initial idea was to rewrite a tool from scratch.
And I looked at that and thought I heard that and I was like, you know, we may not want
to do that because that sounds really, really intensive.
So what we did is over a couple of sessions we figured out some real things that we didn't
know about this particular tool that we wanted to, you know, talking about rewriting.
And what we had was a lot of questions, like what is it, what does it do, what do users
want.
So you may not see all this text, but just the TLDR for you.
There's a lot of spikes in decision making and documentation, like proposals to write
to get community feedback before even setting to write code.
So this is what I mentioned earlier, like the assumptions that we often take into our
development plans.
We had a lot of assumptions that we just had to rewrite this tool because it's just too
broken and, you know, we just do it over.
That's often not the case.
And so I just want to point out that I didn't come up with the idea of assumption-driven
development.
I found a term that someone else created, and in my search to find out exactly who, I came
upon this blog post, which I found really interesting.
It's a developer who basically described his own failure trajectory because he was operating
with assumption-driven development.
And what he did was he decided to just take on a lot of work on his own.
He didn't talk to anybody around him.
He also didn't understand what he was working with in that day, like the tooling and all
of the different tooling relationships, and also the knock-on effects of making changes.
And he kind of went in like, I'm going to do this, say, and like it's going to be done.
And that also didn't turn out to be true.
There was a lot more work involved that he had expected and planned for.
So I thought it was a really great summary from the developer's perspective of why assumption-driven
development is often not the best method to use.
I'm going to give them a talk, and you can ask questions after.
Thanks.
So basically, what I'm suggesting here, like a way to conquer assumptions, is oftentimes
just listening to your environment.
And that starts with the people around you.
So there's this thing called active listening, and I found a nice resource from the Center
for Creative Leadership, and they give you some behaviors that you can adopt, or adopt
rather, to start listening more actively to your colleagues or co-collaborators and
others you work with.
They say, first of all, pay attention.
And we take this as a given, but in our world of smartphones and lots of distractions and
multitasking, we often don't really fully pay attention to each other.
And one way that we don't do this is that we sometimes can't wait to, we don't wait
for the person to finish what they're saying, before we just like, oh, I want to get my point
out.
We have to go, and then we end up missing the latter half of the sentence, because we're
too focused on our own sentence and what we want to say.
So active listening means that you don't do that.
You actually let somebody finish, and then you ask.
And you also can do things like clarify what the person is telling you by asking them questions.
Did I think, I think I heard you say this.
Is that correct?
Or can you tell me more about what you're trying to say to me?
And then together, it starts to become a collaboration, because you're inviting them
to also clarify their ideas for themselves.
And you're also getting higher quality information, because A, you're taking it in, and you're
also engaging with it in a team context to work out new ideas.
In addition to listening to your colleagues and people around you, you should also listen
to your code.
So I mentioned a few slides ago about this idea to rewrite a tool from scratch.
But if you don't really listen to your own code from the beginning, you may end up doing
a lot of work that you could have avoided by just optimizing and selectively choosing
what to work on.
So having artifacts like docs and diagrams will help you to better reason about the work
you truly should do.
Optimize, find the points where you can make things better, and also plan accordingly.
So here's another example from Sig Release where we applied this principle.
We had this tool, right?
And we were going to rewrite it.
But I said, first of all, let's actually document the flow that the user follows to use this
tool, achieve a job, go from point A to point B.
And so an engineer in Sig Release did this, and then we gathered around as a group, around
his workflow, and talked through every step, figuring out what was really hard, what was
taking a lot of time, what wasn't working.
And as you can see from the results, the first line there is the overall flow.
And then I blew up this section toward the end, where you see a lot of anger, and then
there's this little clock, which means it was really time consuming.
And you could then see in the full landscape of this project's flow where the pain points
truly were.
And we were also able to use these posts to document exactly where the code existed that
was executing these steps.
And so what we walked away with was a much more focused plan for what we needed to do.
And we can then start there and then decide after collecting a lot of information about
these weaker points what we should do next.
Maybe we rewrite parts of this instead of the whole thing.
When you have a workflow like that in place, it really helps you to put, it puts you in
better control of your project.
Now if you have no projects, that's fine too.
What we're going to cover next are some tools that you can apply as you start working on
a new project.
But you can also introduce these even if you have something that's several years old.
It doesn't matter.
It's never too late to understand your work and then organize yourself to do the highest
value work in the future.
So I'm going to cover having a strategy with a doc template, doing user research and surveys,
including an example of a survey which is the NPS, making a roadmap and giving you a
template you can use, and then prioritizing and refining your backlog with some methods
and tools you can apply for those activities.
So here's a strategy doc template that I just worked with the security scorecard team on
to actually fill this out.
And I know these little lines here are small and you can't see them.
I'll get to that in the next slide.
But it basically introduces the concepts of the 5Ws that journalists use typically to
write a news story where they need to have the reader know the facts of the story right
away and then if the reader wants more detailed information they can read on.
But it answers who, what, when, where, and why as well as how.
The goal here is that you have an asynchronous tool that you can use so you don't have to
have a meeting around this, although I advise it because you'll find that more information
comes out when you actually discuss your strategy.
But you can at least start with a template like this and people then can contribute their
comments and ideas to it.
This is Miro by the way.
When you actually have this template filled out and you've gone through it with your team
then you can dump it into a doc, refine it a bit more and then publish it in your repository
for the public to look at.
And then of course you can continuously revise as your project develops and you discover
new information.
So those small questions in that template are here basically.
Not all of them but some key questions that are quite useful for getting a sense of where
you're going with your work.
So who are the users as long as the contributors and the maintainers?
But really who are the users?
Who are the people deriving value from your project today?
And who do you want to derive, who do you want to have value derived in the future?
Like who should derive value in the future?
What does your project do today?
On the flip side what does it not do?
I mentioned earlier that boundary about what goes in a project and what stays out.
When you can clearly explain what a project is and what it is not and what it shouldn't
be then you can get a clearer sense of where that boundary lies.
You can also think here about what the UX is like and what quality concerns and constraints
you have.
It's really just like what is your project essentially?
What is your project useful?
So what are the conditions to trigger a user actively coming to you, you're solving their
problem?
Another way to look at when is like how long does a particular stage of your project's
workflow take to be completed?
Where does your project fit in the ecosystem?
So I'm not going to go over the ins and outs of doing a competitor analysis here.
There's lots of templates online that you can look at to do one.
But I highly recommend it because when you take a look at other projects in the space
that are doing similar, solving a similar problem, you can then assess the resources
behind those projects.
Maybe there are even products, so maybe there's like a company doing what you want to do.
So they have a lot of money and they can work quickly and then you can consider like what
you actually have in your time budget to actually pursue.
You can also see what those projects and products strengths and weaknesses are and then use
that information to distinguish and differentiate like what you want to provide.
Maybe it's a niche that you want to really get a handle on and provide a really clear
good solution for that no one else is providing.
Maybe it's just because your project is community-based and other projects and products out there
are like for money and so like you're going to be able to serve the community whereas
those alternatives will not.
So thinking about where your project fits in that landscape is really quite helpful.
That leads into why your project exists in the first place.
What value does it deliver?
Then that puts you in the seat of the user who is actually trying to use your project
and solve those problems they face.
Another question I like to ask around why is the cost of delay.
So if we don't develop this project now or if we don't iterate on it and provide these
features of functionality, what bad things happen?
What bad things happen to our goals?
What bad things happen for users who continue facing this problem without any solution?
What happens to innovation in general?
There's really a lot of interesting conversations you can have around cost of delay.
Then finally how does it work now?
This question is also a really nice hook for you to think about the future and where you
want to be in 12 months or 24 months with it.
How do you want to build this to provide different features?
Maybe redesign the architecture to be simpler.
How do you want to be and how is a good frame for that?
I pointed earlier, we're going to cover some more tools and methods.
The next one is user research and surveys.
Having as much data as you possibly can really pulls you out of your own biases and what
the developer with the assumption driven development blog post was describing.
I only listened to me and it didn't work.
If you're listening to your prospective users, your current users, other project leaders,
you start to get all these different perspectives that can ultimately help you develop the right
most valuable thing and not develop a lot of other things that are going to take up
a lot of effort but maybe won't have such a payoff for you or for anyone else.
Surveys should be kept quick and easy.
I tend to use Google forums.
I mean, I know it's not open source but it works.
I don't ask people to write a lot because you don't want to read at all.
You probably don't have time to read lots and lots of survey responses.
The survey respondents also probably don't have a lot of time to fill out lots of forms.
Using check boxes, multiple choice, rating options from zero to five or whatever you
want to set is your endpoints.
You have numeric data that you can quickly turn into charts like this one which was from
a Google survey and it's just easy to make a chart out of the results.
Another thing I like to remind people of is Please Buy by GDPR.
Be careful about how you're collecting the data of the people who are filling out your
survey.
Make sure they offer their consent before you offer them a chance to give them, to give
consent for usage of your data before they move on.
Another great way to collect user data is through discussions.
Like on GitHub, you can post a question and see people respond to it.
That can be a little more time consuming because you're going to have to read through all of
those answers.
But it can be quite useful too because you get broader context.
If you're in a hurry and you just say, hey, community, I want to know if you want us to
do this thing or not.
You can send out an issue and have them give it a plus one or not.
You can use emoticons, this like votes.
There's other tools out there that product managers use all the time like AHA that offer
this kind of voting functionality for feature ideas.
And finally, interviews which are really can be quite time consuming.
But if you have the time to do them, you can even just do a few.
You can learn so much about your own project.
You can sit and watch somebody try to use it and see where they get stuck, see what's
confusing to them, and collect all of that data and think of ways to optimize and improve.
Oh, I forgot.
This is a really important point to ask them.
With the results, a lot of times when people fill out surveys, it's numbers, so it's all
scientific.
But it often isn't because our users may be giving their feedback from a limited set
of data points themselves because they may not be aware of all the alternatives, all
the directions that your project can take.
They may not have a full understanding of the functionality because they don't have
time or maybe you didn't explain it well.
So always be aware that just when somebody tells you what they want, they may not actually
want that thing.
That may be the best guess that they have that would solve their problem, but actually
in the broader context of other types of users, it wouldn't solve the problem in the
best way.
So just keep that in mind that data can also be a little bit of a trap if not used carefully.
I want to give this example of a survey that you can run very quickly.
If you don't have time to set up a forum yourself, lots of questions, you can still
do an NPS survey.
This is used by lots of companies, but it's quite useful in our context because it just
consists of two questions.
Basically would you recommend my project in this case to a friend or colleague?
And then can you please explain why you gave that score?
So the number is very easy.
You have to put it in some kind of NPS calculator, so I gave you a link to one.
It's also the image source.
You basically put in all that data and then you come up with your NPS.
And then there's different analyses online for like what is a good score, usually it's
20.
When you're 50 to 80, you're doing really well.
So that's from the way that the score is calculated.
It's a pretty low overhead way to collect feedback.
Are we on the right track or not?
I mentioned also the next type of tool I want to show you and that's explained with this
roadmap template which you can adapt to your own needs if you'd like.
I cover some of the who, what, when, where, why questions that I covered with the strategy
doc template.
But the roadmap is more of the short term.
What would you like to do in your next, say, three to six months?
It's taking a slice of your strategy into getting you more focused around what you want
to develop now.
My strong recommendation is to keep it to a page or less so that people can actually
remember it.
Keep the number of deliverables and goals low, like one for three max, using a metric
to justify why it's necessary.
If you don't have a metric, like a baseline to say like we're doing this deliverable because
X number of users want it, then you can also think about the metric that you want to apply
to then be able to measure the success of your feature.
I always like to include risks, like what is known, what is unknown in a roadmap, just
so that with the unknowns you can plan that it might take away time from the future development.
So it might be a bit of a distraction, but you at least are aware of it and you're going
to have to work it out in the future as you go.
And then technical goals.
And this is like to make sure that quality, observability, testing doesn't fall by the
wayside.
I see this happening in a lot of projects and products as well where like all the stuff
that actually makes the thing run gets pushed to the end and then the engineering team is
stuck with a very patchy problematic system that they want to really fix, but nobody has
a lot of time for them to do so.
The next last couple of slides are just covering prioritization.
So this is a matrix that I like to use because it allows teams to take a stack of issues
and then plot them on this matrix.
The matrix asks them to assess tasks, ideas based on the amount of effort along with the
value that they expect to provide for the user once they do the thing.
And then this allows the team to see like if they have a lot of things that are high
value but also high effort, then they either need to maybe focus on one of those because
they're not going to do like 10 high impact, high effort items at once or break them down
into smaller bits so that they can then go into the do it now column which is really
where your quick wins and your low hanging fruit should go.
It's really important to plan for those quick wins to have them early on so that you can
collect momentum and the team doesn't feel like they're just in some long slog that they're
never going to see the results of their work.
If you have quick turnaround for impact provided then that's nice because they can celebrate
those wins early and keep going.
There's also this nice, this is my favorite box, the don't do it box because that's where
you just like close the issue and forget.
Here's where I use this matrix in action.
This is also a security scorecard recently.
We haven't done this exercise yet but I'm really hoping we do it soon.
This is basically all the bugs in the backlog and just putting them in specific buckets
like some of them weren't bugs so that was just really categorizing what's a bug what
isn't.
Then the goal here is the team will plot the bugs on this graph and then we might find
out that some of the bugs were solved, maybe some of them are relevant now but it's really
to kick stuff out of the backlog and then just have the focus on what is really important,
what's really valuable, what are people really being hurt by right now like we should fix
right away.
That's basically the steps for how you would apply such a matrix.
I also encourage using a scoring model.
There's a lot of different scoring models and you can find on Google or Ecosia, my favorite
search engine personally is Ecosia.
You can go in there and see what scoring models can do to help you assess things like reach,
impact, excitement, effort and have a weighted scoring option so you can stack rank your
backlog items and then do the top items first because you've decided through data and analysis
that they're the most valuable ones.
This is another template for your strategy.
I just found this on Miro.
It's by Lou Coleman and basically if you're rolling out an MVP for a new project for the
first time, your center of focus is obviously the tree trunk so making the purpose of that
really strong and solid and then over time you have more time to build on your tree trunk.
This format allows you to plot your plans basically on different bands.
So maybe the future band might be something that's high impact and high effort but it's
just going to take a lot of time so you don't project that you're going to have it done
right away.
I just thought it was a nice visual I like trees too.
Last slide is probably something that's very familiar to you.
It's a standard campaign project board but this really helps with asynchronous collaboration
because if you're running your board really well you'll only have high value work in it
and then your contributors don't have to have a meeting to figure out what to do.
They just pull off from the board knowing that you've clearly vetted your work through
the tools that I've shown you so that they know that what they're going to deliver is
ready to go and it's going to make a difference.
My experience people are really motivated by purpose.
They don't want to just do something for busy work.
They actually want to know they're making a change.
So with your really nicely refined backlog you can help your contributors along by giving
them valuable work to do.
I suggest making a triage work in group or having some mechanism in your team but just
make sure that issues are triaged regularly so they don't pile up and that's a really
good way to get non-code contributors involved as well.
Making valuable high purpose work.
Hopefully I have helped clear your path and helped you clarify your purpose.
This is a nice trail in Amsterdam.
It's quiet and friendly and inviting so hopefully that your open source development can achieve
some similar aesthetics and that's it and that's the links to the resources that I've
shared earlier.
Not a question.
So this goes back to the assumption driven development that made me wonder especially
since you pointed out to stake the work first so you know what you're getting yourself into
but if I do that, if I had done that then I would have never started any effort at any
time because I would have been too intimidated had I known what I would have gotten myself
into.
So what do I do to still get stuff done?
I think it depends on the number of factors.
If you have a lot of time to build something out and really focus on it.