0:00
so maybe let's start at roles of the team uh you mentioned this release Sheriff a product Genie responder a tech
0:07
lead uh project manager product owner you have a lot of roles actually oh yeah yeah yeah yeah yeah and uh my question
0:15
do these rotate are these hats or are these people hats these are hats and the
0:21
fact that um we have so many named roles it is probably a testament to our VP of
0:27
engineering Ryan he is really into playbooks so we have for these different
0:32
roles we have dedicated pages with that describe the responsibilities the the
0:39
reason for a role and what is expected from them and that you know coming back to Performance Management that is really
0:45
helpful but also to set the tone and we are iterating on those two
0:52
foreign welcome to Shapers and Builders the show
0:59
about better ways to deliver great software products today I'm speaking with haiko Barons VP of product at
1:06
memfort an iot reliability platform before joining Memphis had an impressive
1:13
career in engineering roles at Pebble smart watches working on augmented reality devices at Intel and most
1:20
recently on the Oculus VR headset at Facebook meta this conversation is part of a series
1:27
about companies that use shaper a delivery framework originally created at
1:32
Basecamp if you've never heard of shape up check the show notes for a link to the video shaping in a nutshell by Ryan Singer
1:40
former head of strategy at Basecamp and author of the book shape up stop running
1:45
in circles and ship work that matters in our conversation haiko walks us
1:51
closely through the product development process at manifold and how they have adopted and adapted shape up to their
1:57
liking what struck me the most was how rigorously Haiku and the team have designed their process including
2:04
detailed playbooks for the hats that different people wear at different times it feels like Haiku and the team are
2:11
tackling this process designed very much like an engineering problem even keeping a change log of how the process evolves
2:18
with each cycle we get to talk about various tools that the team has developed to for example keep track of
2:26
scopes of work plan who's available and manage well-formulated project briefings
2:32
haiko also underscores that it's important to embrace the iteration in how you work and that there's no end
2:39
state of Enlightenment that you're trying to reach so without further Ado let's get into our conversation
2:46
[Music]
2:53
I'm very excited to be speaking to you today um you've had quite the illustrious
2:58
career could you briefly take us maybe through the formative steps that led to
3:03
your role as head of product at Memphis now I've been in the software industry for
3:10
almost 25 years now selling software there making software I am a programmer
3:16
by heart software engineer and I've done anything from being an individual contributor in small companies did game
3:24
software for tax advisors and lawyers was a consultant for you know financial
3:29
institutions like the New York Stock Exchange did things such as tooling for
3:35
programming languages mobile applications you name it and then I've been like a software like an engineering
3:42
manager architect CEO of my own startup ones which failed miserably and then I
3:49
moved to the Silicon Valley joining a startup called Pebble SmartWatches we did the first SmartWatches before Apple
3:56
watch or Android Wear had been there that also failed and from there I moved
4:02
over to Intel the the chip manufacturer where some of my former teammates joined
4:07
me over there and then we built like had worn embedded devices and then after that I went over to Oculus VR headsets
4:15
Oculus is um part of former Facebook now meta and
4:21
when I moved back from the valley back to Germany where I'm now I left Facebook and instead joined friends of mine
4:29
um in their startup manfloat but what do you all do um can you talk a bit about how big is
4:35
the team how long has the company existed what's life science right I looked up those numbers to be
4:42
prepared for it because that changes um continuously we are hiring Shameless plug and so I had to look at the numbers
4:50
of the week when I joined um we were in total of 14 that's one
4:56
four people with eight Engineers so pretty heavy um and then I would separate that into
5:02
none ICS non-individual contributors at the point that was our CTO
5:08
um and then the rest was product engineering I must say that our product it's a SAS web application but it's not
5:17
the traditional stack it's fairly um diverse and it's Tech stack because
5:23
we are doing three major functions for the embedded world and in order for to
5:29
do that we have to have an on-device agent so it's not just a web back end and web front and we have to have code
5:36
that runs on these teeny tiny very constrained devices and that leads us to the need of an SDK for
5:44
super small scale microcontrollers that have kilobytes of RAM and code space over Android AOSP with megabytes of
5:53
space sometimes even gigabytes and then the third category which we recently started to support is embedded Linux so
5:59
our team needs to be able to understand these Stacks to talk directly or indirectly to our backend we have
6:05
companies that run like scientific drones in the Pacific talking to us via
6:11
iridium satellite uplink with like very low bandwidth and then we have other companies that have continuous internet
6:17
connection because it's an embedded Linux device on the on the ethernet and that all talks to the back end back
6:23
end is really challenging because we have these millions of devices continuously talking to us so we have
6:29
not the usual setup where you have you know a postgres SQL database to query whatever you want that just doesn't work
6:36
and then on top of that ultimately that comes like you know an API surface and web front end so all of this had been
6:42
built with these eight people or seven at the time and then I joined um as the first product person dedicated
6:48
to product and what I didn't tell you and my intro was I've not been a product manager in my entire career this is the
6:55
first time I was doing this it was scary but um when I was um
7:01
considering new jobs two former friends of mine and CEOs of two
7:07
different startups independently asked me if I wanted to be their like product person
7:12
both very technical products and and then I read up a little bit consulted my network and asked other product people
7:19
um if that if they would consider me to be a product person and they always saw me like that and that was interesting I
7:26
certainly can relate to our target audience I formerly was one of ours but
7:32
I I clearly was lacking the experience in the actual doing the the tool belt
7:37
was just not there unlike software engineering of course you did mention you founded your own company right oh
7:43
yeah yeah yeah and you were the CEO and you were kind of thinking about product of course so product thinking was always
7:50
top of my mind even in my other functions you know as a tech lead or or architect or when you are maintaining an
7:57
SDK for um like a product with a substantial user base you clearly think with product
8:04
and mind but for example like if I say rice here
8:09
every PM will immediately know what that means I didn't know at the time I mean roughly I mean I mean if you if you talk
8:16
I mean I mean it's ice oh yeah and I studied business administration next to computer science so sure I have like a
8:22
business background and if I had as an engineer heard about rice I would have thought I mean this is so obvious why do
8:29
you even care and yes many of these tools are obvious if you think about it but having common language and
8:36
um shared experiences on top of um the same methods goes a long way so
8:43
like having tools and Frameworks are really um liberating I find and not so much
8:50
narrowing your your abilities to act anyway you asked me about company size
8:56
and I think that is today so today we are that's two years later Grew From 14
9:02
to 47 as of this week and we are still hiring and we're very ambitious did I
9:07
tell you that we are hiring we have amberish's hiring goals across the board including our product team
9:13
engineering is 16 people now and I would contribute uh split this
9:20
differently now none I see so that's Founders and management we now have management level here is four people and
9:28
then we split our engineering team and I'm sure we will get to those later in the conversation but we we started with
9:34
a very homogeneous perspective of our engineering and now we split this into solutioning and devex
9:42
Engineers that directly interact with our customers who are also Engineers our
9:47
solution needs to be integrated into their product that's five
9:53
we split off a platform team as one of our many learnings um when after we introduce Shape Up
10:00
their platform team consists currently of three people and because of like different circumstances we are down to
10:06
four product engineering people that is nothing this is like much smaller than
10:11
what we started off with especially if you consider that our product team now contains two people not just me but
10:18
another very talented product manager um so in total this is like 18 people
10:25
involved in engineering but depending how you're looking at it only
10:30
four Engineers actually being doing product engineering we this is the four
10:36
is the area where we had like a larger number in the past of course where we are hiring
10:42
um the most aggressively because um the number of these people determines
10:47
how many Builder projects we can run in parallel and the kind of downsizing tufo
10:52
is that a temporary thing is that a result of anything in particular oh yeah that is a result of like many learnings
10:59
I think two major factors contributed to this um we
11:05
had to let go our people in the most recent past um who were not
11:11
working well with this mode where you are a builder and responsible
11:17
um by yourself the learnings we took is that we need to hire um with that entrepreneurial
11:23
um my and and um pragmatic perspective in mind we also focusing on very senior people these
11:30
days and I have a long list of laws I see in shape up and I think this is maybe not a flaw but an implication you
11:37
need to have a team that is compatible with it and the other one is we separated that
11:44
platform team and that is in turn also a learning um and maybe it's also entangled our
11:51
text tag is as I mentioned fairly complex and so it it requires
11:56
um breadth to fully understand how to work on a particular area in an area on
12:03
a feature and so the platform team's goal is to simplify certain areas document them better putting in place
12:10
safeguards but also most recently the platform team is helping us to
12:17
evaluate and explore technical feasibility before so you can see this
12:23
as either shaping or pre-shaping before we even start a project so that there
12:28
are fewer unknowns before we start a project and then last not least the platform team is there to support the
12:35
Builder team so they are not completely off the chart but they are
12:41
not within the people we can draw from when we produce what we call a cycle
12:46
plan yeah yeah cool and we'll get into kind of detail on on all of these things
12:52
um but it's good to have the phrases out there to draw um drop on it cool um I think this is a
12:59
good time to kind of transition a bit into talking about Shape Up and to kick
13:04
things off there I wanted to ask you how did you get into shape up what were your first encounters with it and what was
13:10
your initial reaction to it yeah so as I said I'm doing this for a while when I
13:15
started there was no scrum and uh and then in the most recent years I would say in the past 10 years scrum was
13:22
everywhere and agile agile methodologies and that that could either be kanban or
13:27
scrum what I noticed is that oftentimes that was uh an ever-growing backlog of tickets
13:36
that were at least at the top of that um pile of of tickets roughly stack ranked
13:43
by priority and then you had various forms of grooming meetings where tech leads or
13:51
knowledgeable engineers in certain areas plus pm and then maybe sometimes stakeholders were trying to assess what
13:57
to work on next and then there are various boards sometimes one board sometimes topic oriented boards and you
14:02
would push them from the left onto the board to very detailed explanation of
14:07
the tickets to a facilitated Handover and that handoff and then an estimation bottom-up estimation and then of course
14:13
like you have velocity aim for so many tickets and then at the end half of it at best gets done because
14:20
priorities changes over time and as the missions are off and very
14:25
frustrating and that's roughly where mempod was before I joined
14:31
no surprise here I mean this is how many companies I'm aware of are operating
14:36
right now and some are better at it but that's not because of process but because of their past experience and
14:42
individual Talent at it and then when I joined
14:48
um I you know I know the team for a long time so the founders are actually ex-pablers and
14:54
um I was even there when we had been discussing whether or not to create a company out of this idea of building a
15:00
iot reliability platform as we do now with memfold I didn't want to join those
15:06
startup at the time but I was involved very early in all of this and and then later joined two years after it um it
15:12
was around and at the time most if not all of the engineers were ex-peddlers and people I worked with and
15:19
one person who actually introduced shape up to the company Fausto he he was not an expeddler and so he was very fond of
15:27
shape up and he introduced me to this book so I read the book I have the book here and
15:33
um I was basically laughing at it you know arrogant engineering perspective uh
15:41
nothing new here Hill shots this is just a glorified progress bar who needs that
15:46
like vertical bump and who knows needs this like potato shaped scope maps and
15:52
like all of it is basically just um more fluff then um some you know real like usable advice
15:59
and then a few things really helped me here and I'm not sure I'm not
16:05
sure how I got to this but what I realized later is that um I really liked time boxing
16:12
time boxing and then the circuit breaker I like the idea of
16:18
um not managing individual projects independently but rather having cycle boundaries because it would allow me and
16:24
I'm not sure this has been said in the shape up book but what I wanted to introduce is the ability to rearrange team constellations based
16:32
on the projects and if you have Circle or cycle boundaries it is ensured that
16:37
everybody becomes available at the start of the next cycle I found this really um intriguing
16:43
and then the reason why the team had introduced this was desperation like
16:49
being desperate but also they wanted the engineers wanted autonomy and that is a
16:55
two-edged sword I think it works kinda in our world because our Target audiences are primarily Engineers
17:02
so Engineers have customer empathy but to this date we don't have a single
17:07
product designer we're hiring and it is all on the engineers
17:13
and um but I I could see that this would happen regardless with or without shape
17:19
up and why not embracing it so when I joined the first ever Shape Up Cycle was
17:25
um just like it just had started and it it was a disaster like I think
17:32
with these let me look at my numbers um eight people in total let's say seven
17:38
people um they were all like running in circles I think we had as many projects scheduled for this first cycle as there
17:43
were people and like nothing got complete and it was a disaster but um it set the stage and then from there
17:50
we continued and oh yeah I have even more concerns about shape up it should actually drop them just here or like how
17:57
do you wanna there will be space definitely to explore kind of the Fall so I think to
18:03
structure the conversation I would say let's talk about what you have what you learned how you iterated and then where
18:10
you are now and then talk about what is kind of what Still Standing issues you have with it
18:15
okay so we do have a backlog of no changelog I can pull this up real quick
18:21
I I won't share the actual details but I can scroll through it um so what we maintain from Circle one
18:28
is a change log of all the things we were changing and we we tried things out we learned they were better or worse and
18:34
then move uh back so what entry are you on in this in the change log uh we are
18:40
at B18 that is a builder cycle 18. so first of all the observations
18:46
I made even before um we started cycle two was that this was
18:52
unrealistic as um we are still a startup
18:57
and maybe if you have a very mature product um what is being said in the product uh
19:02
book is true but like the idea that bugs are nothing special and you can wait um for six weeks until you address them is
19:09
not working period um we have constant fires everywhere and
19:17
something simply cannot wait for six weeks so we needed a way to address them earlier at the same time I really value
19:25
the idea of uninterrupted uh thinking deep thinking time as a former engineer
19:30
so what I introduced is the rule of a what I call a responder that was like inspired by first responder and
19:38
um so um they are there for emergencies and the responders goal is to Shield
19:43
Builders from anything that happens unpredictably
19:51
yes so um well I mean they are part of the cycle plan so what we do before each
19:56
cycle is we create what we call a cycle plan uh that that actually that
20:02
materialized much later we realized that people were not always sure
20:07
what was going on because we were shuffling team cancellation to best meet
20:12
the requirements of each Builder project and and so like what we introduced is this artifact called a cycle plan that
20:19
is usually ready the week before the cycle starts sometimes earlier and there
20:24
think of it as a it's basically a calendar you have
20:29
horizontally the weeks of the cycle and then each row is either a project for the Builder projects or the individuals
20:37
if you have different other functions and then to the right it's either a large bar depicting a project or if it's
20:45
individuals also when they are out vacation time or anything or what other
20:50
roles they have we have since then introduce roles such as the release Sheriff shepherding along releases or
20:57
product Genie who helps our customer success team with product related questions that basically at the
21:04
traditional term for this is probably sales engineer and that is like that schedule on call
21:11
that that is all like visible there for the upcoming cycle and then we use it as a communication tool
21:18
um how did we get there it's I was asking if the uh
21:24
if they sit outside of the projects I guess well yeah outside the product we still see them as part of the cycle
21:31
um and we deliberately put them either like down to that responder um role or in one particular project
21:39
deciding who should work on a particular project is it delicate
21:44
um exercise many um um inputs go into that decision making
21:50
process um and it's not what you might think as in first and foremost skills
21:55
it's not just like who knows um the problem space the best to work on a
22:00
particular project it's also um another thing we introduced are formal
22:06
roles we have the role of a tech lead with enable the team the one person who
22:11
ultimately like Shepherds along with the other engineers and um makes like critical decisions is the
22:18
person talking to other stakeholders we have the project manager also coming
22:23
from engineering which is sometimes tough but we learn we also tried it not um being from Engineers but
22:31
um we learned that you need to have like deep knowledge about the daily circumstances of the engineer who
22:37
sometimes is stuck and everything in order to do um very detailed management
22:42
and then a third rule we have in each project is um provided by product which is the
22:47
product owner and their rule is to answer questions about value for uh and
22:55
and like if there are certain Alternatives um assess which one is a better
23:01
compromise from customers perspective not so much effort or timing but really this
23:07
and they also help the Builder team Gathering additional information with like if absent if it wasn't present in
23:15
the pitch um during the during the project to basically shielded the builders further
23:20
so I think yeah many of these learnings went into how do we best allow Builders to focus on their
23:26
projects timing is another thing we went from six weeks to hey let's have projects of
23:33
different sizes we call them it was a part of the book like small batch big badge yeah so like we discarded that in
23:39
the end we went down to four weeks and we are now at five rigs this is not
23:45
because six week is the magical number or anything it kind of is I think like we need at least four weeks
23:52
but we also learned that we are a product company after all and other
23:57
functions such as sales and marketing needs to be aligned and what we are doing right now is a five plus one one
24:05
being one week of cooldown we also had like two weeks of cooldown in between [Music]
24:10
um so that if you put two of these together you have a full quarter
24:18
that doesn't quite line up you need one extra week so we have every other cycle we have two weeks of no Builder cycle
24:25
and that is usually when we schedule a an offside or something as well
24:30
um but yeah this is coming up at the next cooldown at the end of this quarter is going to be two weeks
24:36
um where we are again meeting in Berlin and um not only work on stuff we otherwise
24:42
don't get to but like discuss a long-term perspective and and anything else that you do better in person
24:49
I would say let's now talk about the main pillars of your adoption of shape
24:54
up today and I want to break this down into the parts that the book kind of has which
25:01
are shaping betting and building if that still makes sense for your context yeah it does
25:08
so shaping uh we still have pictures we oh that's also one of the first
25:15
things I changed I found the pitches to be too um
25:20
disconnected from the business so our template includes business
25:26
related items as um what's the value of this and I don't mean I all of this is from
25:34
the perspective of memfault you might be tempted to declare the value as an O after this feature is there the customer
25:40
can use the feature well um well you that's of course like a um
25:47
tautology you then sometimes say well happiness increases cool but then like how you
25:55
need something that is makes pictures comparable to other pitches and the reason is I sometimes got the impression
26:01
from the book that this is very Ivory Tower Bridge a few distinguished people
26:07
get into a room and then come out with a decision what we do instead is we we
26:12
discuss this fairly in the open ultimately it's on me to decide what to work on but
26:18
um I want people to understand the decision making behind it and for this to be transparent I put business value
26:24
out of it and that includes what what's the value of it and then very important why is it
26:29
important well in the startup everything is important but then combined with why is it urgent why do we need to put out
26:36
this particular fire right now why can it not wait another six weeks and if you are really diligent about that
26:43
I would Echo what has been said in the book it's yes many things can actually wait for six weeks these plannable
26:48
things um there are always customers who yell the loudest at you or
26:55
um are at the verge of um churning or whatever but like ultimately most things
27:00
can wait another cycle and now it's you look at things in value importance and
27:06
urgency before even looking at the solution and so that enables a lot of people to
27:12
contribute to the shaping process you can now suddenly pull in customer success and sales into the craft of
27:20
creating pitches and that's what we do I must admit that the full pitch I've
27:25
never seen a full pitch exclusively being written um by anyone without the help of product
27:33
but we have one very successful pitch improving our demo data for our sales
27:39
reps like they are doing sales conversations we have a demo instance of our product and they want to show
27:46
um or like use the product to support a certain narrative and the demo data we had was not cohesive in that narrative
27:54
so we had to have particularly designed demo data on our product and that was done
28:01
um with our like with with sales and um together with product and is a huge
28:08
success it's not really directly a feature in our product but ultimately creates a value in the company and I and
28:14
this this distinction to me is very important product is not just there to crank out features it's there to improve
28:20
company value uh as a whole so making that separation is important and then shaping everybody in the
28:27
company is invited to do pitching technical solutioning mostly comes from
28:34
engineering or product I'm trying to hire technical product managers who can
28:39
also do solutioning at a fairly technical level and we are hiring and
28:47
um yeah so that leads to oftentimes the the upper part of the pitch being contributed by others but then
28:53
solutioning ultimately um product I'm just going to ask you on on that um because I I've read a bunch
29:00
of case studies on Shape Up where teams are saying pitches can come from
29:06
anywhere but rarely have I myself personally seen this happen did you do
29:12
like did you train the other tips in any particular way to to enable them to kind
29:17
of break down this barrier yeah so what we do is yes
29:23
um I think um if you a few weeks after I initially joined I
29:29
ran a company-wide workshop as part of our offsite everybody in the company was involved in
29:36
you know taking a step at pitches um we tried this on and off so I think maybe in total we tried like three or
29:42
four instances where people were strongly encouraged to contribute pictures um I would say that this was not the
29:49
main facilitator instead what we instantiated
29:55
um is what I call now a shaping meeting it's a weekly meeting where I pull in
30:00
the different functions of the company so that is a
30:06
standing meeting where I have customer success sales
30:11
engineering CTO formally also I'm our CEO but he's not part of it anymore and
30:18
then myself and that is mostly to get perspective on things from these
30:23
different angles I want to call out that marketing is not part of it maybe we change that in the future
30:31
um too many cooks is also a problem but then this is primarily at the beginning of each new shaping cycle
30:37
um a way for me to get a fresh perspective on things but what it also means is that these people don't think
30:44
like on a daily basis in pictures and products and and projects on anything but rather they have like all these
30:50
learnings and concerns and now you funnel that into digestible
30:56
clusters and say you know that would be a good pitch candidate and and now it's their motivation to somehow get to such
31:03
a pitch and I think from all of the engineering certainly contributes sales as I mentioned Demolator for example but
31:10
then also especially customer success Andy she's leading our La customer success team is really behind the idea
31:16
of pictures as a tool to get um attraction for her team and and then
31:22
she delegates that to to her team and ultimately at the very least they
31:27
come up with that top part and especially and we also pull in customer success um basically for every pitch to justify
31:34
the importance and and validate the urgency so I would say
31:41
it has been planted as a successful idea people realized that um this structure
31:47
really helped us getting away from this running in circles constant firefighting which took us roughly six months after I
31:54
joined they saw that we could really deliver things with this tool and I
32:00
think it's to the leadership of the company um recognizing this and then carrying it
32:08
back to their respective teams and also the value of the the standing meeting I think just keeps it top of
32:14
mind and yeah it's everybody into this process right so that's also different
32:20
from the media from the book we didn't have this right away I don't know exactly when we introduced this but the
32:26
sending meeting is basically a um it converges towards the betting
32:32
table the betting table is the last so to speak um meeting of a giving shaping cycle
32:38
it's not just a singular event what happens is that we have um for each new
32:44
cycle or we have one notion page where we are discussing that there's like a
32:49
standard template for the first opening meeting like let's get together let's collect everything is everything still
32:54
wherever you think it is did we learned anything is anything like urgent to force us to think about it of course
33:00
that can happen at any time and then that uh produces pitch candidates or
33:06
pulls pitches out of our pitch back lock we have a backlog of pictures
33:11
and put it onto um it's basically yeah another Board of
33:17
potential of pitch candidates for a given cycle and then it's a function of how much
33:24
time do we find to flesh out and shape the pitches which is indirectly a
33:30
measure of is it really that important and also availability of people and
33:36
steadily we narrow down which pitches will ultimately make it
33:42
and we use this time of Discovery to also go back to the platform team for
33:47
example to a form and form technical feasibility or customer success going back to customers to understand
33:53
urgency better and then ultimately I think this way we have really well informed data when we finally place our
34:01
bets but I must say that the betting table is fairly uneventful at this point it's almost always already decided
34:09
at least like informally and another point of awareness we do
34:15
have a company meeting a weekly All Hands Where I report on not only the
34:22
current Builder projects and their progress but also what we currently think of for the upcoming cycle so that
34:30
people are aware interesting so the those weekly meetings
34:35
they aren't the same agenda every time but what you talk about depends on the life cycle of where you are towards the
34:42
next starting the next cycle yeah there are like always goals as in um we need
34:48
to have locked down um the candidates by this week so and
34:54
then like to drive some urgency there are there's this limbo state of
34:59
the first weeks of a builder cycle where nobody really feels urgency to work on these pitches
35:06
um and so you need to like you know drive this a little bit where do you pull the resources from when you have a pitch coming from
35:12
customer success to help them go into the solution and so I imagine you know
35:17
they are very strong in filling out as you mentioned the top part about the problem the value and the urgency the
35:23
importance um and then in the first one or two weeks of the ongoing cycle I assume that
35:29
you then kind of say okay this is something where we feel like we we can push for a solution and shape a solution
35:34
so we can bet on it next time how where do you pull those resources from to get to the technical solution
35:40
so customer success as I said is very motivated they have
35:45
access to our devx and solutioning team anyway and they oftentimes
35:53
present pictures that are directly informed from particular recurring customer need and those Engineers have
36:01
the skill to write out at least the solution at the boundary to the customer that is not complete but at least it's a
36:08
starting point and then we use like product management time to do the
36:14
refinement and everything the fact that these pitches are incrementally and openly written is also
36:24
allowing us to pull in to ask for feedback early on so
36:29
honestly oftentimes pitchers are not ready weeks before but only days before
36:34
but at least rough structure is there and then we ask oftentimes either the
36:40
platforms like the most knowledgeable um Engineers or the engineers we foresee working on these pictures in the end to
36:47
give early feedback and to socialize these ideas and then you refine I think almost always it's ultimately a
36:55
product uh during the final solutioning before we oh and we also had cases where
37:02
the pitch wasn't even ready and we still Bet On It but it's um ultimately it's ready before the kickoff like kickoff
37:10
is where you go through the entire again we have a
37:16
template for this as well like the kickoff meeting but it's ultimately deciding on these rules and the team and
37:21
then um going through the pitch they have done this asynchronously before uh collecting
37:29
answering all the questions that can be answered immediately but leaving with a set of questions we need to Circle back
37:34
on so that we can start with scoping I feel that we already going into the scoping I want to say one more thing
37:40
about the shaping phase um cycle plan is absolutely important
37:46
the cycle plan informs the betting table and vice versa
37:52
this is really entangled and our we had a recent inflation and titles
37:58
because we are startup and we're growing um VP of engineering I'm actually not a head of product I'm actually BP of
38:04
product um we had this ongoing debate about
38:10
um what comes first betting placed bets or cycle plan I always wanted availability
38:16
and preferences of team members to inform what bets took place how to staff
38:22
these projects and then ideally even know so early that I could know what to where to invest the most time shaping
38:29
time on so that is and then ultimately it is it is a mix it is um we're very entangled
38:36
but this cycle plan really helps as a communication tool and it's crucial for
38:42
engineering because we use like in an organization you always need
38:48
to do Performance Management and evaluating um how somebody performs but also if you
38:53
have new people how to onboard them um if people if Engineers want to extend their skills
38:59
um where to put them and with this very Dynamic concept of shape up you need
39:05
something that accounts for that too and the cycle plan and the close discussion
39:11
with our VPO of engineering is the tool to allow for that
39:16
interesting I did want to um ask you one thing about betting that maybe takes us a bit off the Reds but
39:23
I'm still gonna do it um because you you leaned so heavily on the aspect of urgency as part of the
39:29
decision criteria that you have and I wonder how you balance that with kind of a more long-term view on where you want
39:36
to take the product yeah one of the many flaws of shape up it doesn't have an answer to that right like what about
39:42
roadmap um what about tasks that don't fit in just a single cycle
39:49
what about tasks where you have one-way decisions not like clearly a shape up
39:55
comes from a front-end heavy product team where you don't have long lasting contracts and humans the the end users
40:01
are very um um forgiving when it comes to changes every
40:08
in others cycle we have a product where our SDK runs on these millions of
40:15
embedded devices with an SDK that is only updated every so often so some
40:21
design decisions are very hard to correct you need proper planning and
40:26
that is not really specific to shape up it's more agile methodology in general but like these are all problems that
40:33
shape up has no real answer for so roadmap I am not a big proponent of road maps in
40:41
general at least not in the classical sense where you predict uh delivery
40:47
dates of features um that's very much against the idea of
40:54
um like an agile company if you have found product Market fit and
41:00
you have um like government contracts sure um I think we have roughly product
41:06
Market fit for our initial set of features but still there are so many obvious and undiscovered things it's
41:14
about when to deliver them and I don't want to make commitments because that um there was down our options I totally
41:22
recognize that marketing and sales depend on this to make promises but we try to not make promises
41:28
so that's roadmap we have a substitute which I call River system
41:34
is actually not so much a one-dimensional thing or like multiple Lanes it's more
41:41
you know to talk in mathematical terms it's like an Asic leg directed graph of
41:48
um Petras like things depend on other things you need to ship something in a certain order they are not just on a one
41:55
axis but we need at least these three things lead to this one and then it enables certain other things
42:02
that allows us to understand roughly um like several things first in which
42:08
order do we have to do something what is on the horizon to give perspective and Direction but also sometimes we had a
42:15
goal last year where we wanted to ship our Linux SDK you can work backwards and see we actually need three Cycles to get
42:22
to that if we want to get it done we need to have the first one now and that
42:27
that actually happened to drive urgency in the at the betting table we said okay so like this is a given we have to have
42:33
this because otherwise we won't get this done is that strictly a roadmap but it's helping for this perspective thing we
42:41
also have larger topics where we know early on that this is not going to be
42:46
doable in a single cycle and there it's yeah I think I always wrote those
42:51
um it's basically a more like an aspirational design dock where I'm describing a solution
42:58
Howard could be in roughly a year and then people review it as a as we do
43:04
this at Ben fold with rfcs and and they they look at it as if it was a like real
43:09
project description but it is not it's a source to draw pictures from
43:15
and this allows us to pick from the larger description
43:22
depending on the current needs and immediate value without losing that like a longer term perspective so we have one
43:29
feature that led to I would say three yeah I think three projects in total and we have another one which we call Fleet
43:36
sampling interesting thing I think you will find that if you Google menthold and Fleet sampling it's really unique to
43:42
our product but um John our like PM uh he said
43:48
it's probably the eighth project now we do a run Fleet sampling is that a smell
43:54
and I don't think that's a smell I think so what we don't do is doing one of
43:59
these um projects one after another but rather we have perspective and we decide again
44:06
after each cycle what to work on next and more often than not it's really surprising to me and people who have
44:12
done shape up for a while probably have noticed this too something like a close Contender like the third project we
44:18
didn't get to in one cycle isn't necessarily even on the table the next time and and
44:24
um that here translating to this aspirational design dog oftentimes means that you have one cycle working on it
44:31
and then there's a cycle without working on it and maybe another one and then two consecutive ones and it really depends
44:36
on the immediate value and Market situation that informs when to work on
44:42
it but the aspirational document gives you the perspective so that each
44:48
individual pitch is not in isolation is that one more yeah we have
44:54
um our pitches sometimes we are lazy and we do this backwards in our solution we sometimes add stretch items knowing that
45:02
we most likely won't get to it and then we haven't talked about building yet and we will be terribly out
45:08
of time here um building has one artifact at the end which we
45:14
call a project a debrief where the team themselves describes what they have accomplished how much of this is
45:20
immediately adding really value they're jotting down the known limitations and then there is a section
45:28
planned work like that we committed to work on that's usually cool down you know the last few things or we sometimes
45:34
bargain sometimes bargain with future responders or the platform team thank you cycle plan to have that
45:41
ability like to open up that possibility and then we have possible like future steps
45:47
and that is basically direct input for future pitches and then the future pitch doesn't necessarily need to be in the
45:53
next cycle refers back to this one and also gives perspective interest yeah I think these are our
45:59
tools for this I guess [Music] we'll be enjoying the conversation I
46:04
wanted to take a moment to thank you for listening and to let you know about the Shapers and Builders job board on
46:11
Shapers dot Builders yes that's the domain you'll find jobs in software
46:17
development design product management and other roles at companies that work with Shape Up many of these rules are
46:24
remote and teams who use Shape Up generally run at a more sustainable healthy and meaningful Pace than the
46:31
hamster wheel of two-week Sprints so if you're looking for a job in Tech or
46:36
trying to find great people head over to the Shapers and Builders job board at
46:42
shapers.builders now let's turn back to the conversation let's talk about building and we've
46:49
covered a lot of ground so I think we can speed through some of these um what I did want to talk to you about was the
46:55
roads on the team and you've kind of given an overview stretch Scopes I have here I wanted to talk about then the
47:01
circuit breaker for sure because this takes guts and I want to hear your perspective on it
47:07
um and then maybe whatever other tweaks you have what other hacks you found um yeah on the building side so maybe
47:13
let's start at roads of the team uh you mentioned this release Sheriff a product Genie responder a tech lead uh project
47:22
manager product owner you have a lot of roles actually and my question do these rotate are
47:30
these hats or these people hats these are hats and the fact that we have so
47:36
many named roles it is probably a testament to our VP of engineering Ryan he is really into playbooks so we have
47:45
for these different roles we have dedicated pages with that describe the
47:51
responsibilities the the reason for a role um what is expected from them and that you know coming back to Performance
47:57
Management that is really helpful but also to set the tone and we are iterating on those two
48:03
um so the responder we can maybe take this out but like the responder is basically working off of
48:10
um a kanban board um to work on the most recent
48:16
um discovered very urgent things that cannot wait and then there is also downtime where we
48:23
have planned work you know this traditional backlog of things that are not quite large enough to justify a
48:30
buildup project and so this is managed by product
48:35
not during cooldown during cooldown the board is owned by the platform team because it's meant to work on technical
48:42
stuff and improve the situation so then ownerships toggles at this for this one week
48:48
and so we have this one lane that's called a top top Lane that says like
48:54
like drop everything else we need to work on this now and then every um but other than that we try to have only 10
49:00
kanban board like 10 active um tickets and then people can choose from it we have the Builder and then within the
49:07
Builder we have um the tech lead the project manager and then product owner owner is coming extra from the outside
49:14
from product Tech lead is um responsible for all technical
49:20
decisions um when there are like two ways to to do
49:25
something they need to have the foresight to not dig yourself in a corner for example I
49:31
mean that's ultimately you have that in every team I think and no matter if shape up or not and then um the project
49:38
manager is interesting because there is this
49:44
what to ship and when so in our Playbook we say we want one shipped
49:49
scope within the first two weeks we call that the unambitious scope
49:55
and that is try to drive the idea of shipping incrementally
50:02
we totally recognize that there's often a discovery phase at the beginning of each project so you need to be really unambitious
50:09
with this scope and to ship anything and um doing all of this deciding what to
50:16
work on who to work on this that's the responsibility of the project manager and of course you need to have like deep
50:21
technical understanding and also understanding of the skill set of the people you have there on the team and so forth
50:27
to help with that we abandoned like first of all these potatoes like
50:33
here cover up the book like these these Maps I think are not 100 useless what I like about it is
50:40
two things the circumference shows it as a closed problem a close
50:48
problem space and then also there is no overlap I really like that so like what you work on is
50:55
um by itself complete yeah uh sometimes you have you know if you have a time at
51:01
the end you polish everything but um ultimately I like that and then thinking of it as a vertical slice like this is
51:06
truly shippable um that I like about this but otherwise I think this is fairly useless what
51:13
um helps really to drive that project management discussion is dependency like again within a project you oftentimes
51:19
have we do this first I'm not talking back in front end I'm talking this deep
51:24
vertical thing and then it makes sense to do either of these two now if it's either of the two what how
51:31
to decide to work on it well you could say always the one with less effort or you say maybe it's the most value but
51:38
then what is more valuable and this is where um the product owner rule comes in and the project management ultimately
51:43
decides so what we settled on is a two-dimensional representation of these scopes
51:49
deep um showing them as blobs by them by themselves but not
51:54
within this potato but rather um as you know a dependency graph and then we have two axes one to the bottom
52:01
like top down is time this is what we intend to work on and then left to right is the value each presumed shipped scope
52:09
rings and the PM helps um deciding what adds value and only the
52:16
engineering team really knows the effort and then we are trying to find Alternatives well if this is so valuable
52:21
but so late can we do something you really see that right like oh we do all these things and almost none of them add
52:27
value only this one last thing adds value how can we somehow maybe split this or do anything to get to Value
52:34
earlier and this visualization really makes this obvious so that's why these
52:39
roles are so important because um the the timing and the dependencies really comes from within the builders
52:45
and the value comes from the outside and the product owner so that's what you call enhanced scope
52:52
Maps right yes that's yeah I shared for the audience I shared notes and what they read beforehand let me actually go
52:58
through those um no overlap yeah that's what I like but top down left right skip Loop uh yes
53:04
this really blobs with arrows in between Engineers tend to think in dependencies
53:10
regardless but they oftentimes don't think and Scopes as individually
53:16
shippable features so Engineers would like to do the foundational work uh that by itself
53:23
has no value and then you really need to train to do not the 100 foundational work but
53:30
forty percent forty percent and then the additional 40 yes that is now redundancy because you cannot do the clean
53:38
Foundation but if you do only 40 foundation and then some that builds on it you have something shippable and that
53:45
that is something you need to train and that is again I think regardless of shape up or not this visualization helps
53:51
and then this is why these roles are important I find but Shape Up enforces it maybe more than a Sprint that just
53:58
carries over what didn't get done into the next right Fair yes oh and then
54:03
looking at the circuit breaker and then something probably so that we
54:09
really embraced at Facebook so Oculus is Facebook everything at Facebook was behind a
54:14
feature flag and people may not know this people are not even on facebook.com anymore but people
54:22
um who are on facebook.com are simultaneously roughly in
54:27
about 300 parallel a b tests different ones like you open
54:34
Facebook I open Facebook and we see we are subject to different code paths and we are subject to three 300 totally
54:40
independent experiments there are thousands of uh concurrent feature Flags
54:46
and every development happens not in feature branches but on Main Branch and you guard them with feature Flags so
54:54
when I joined Facebook I thought that's great they must have discovered a fantastic way to avoid that inherent
55:02
complexity you know aspect oriented programming or something who hasn't seen the code base that's far
55:09
from the truth it's um it's a miserable um
55:15
it's a miserable mix of if statements and and different other patterns it's very unmaintainable and really difficult
55:22
if you think of it like if something at the beginning of a function or somewhere and then asynchronously
55:27
somewhere else functionality that needs to match depending on a feature Branch like this is very complex to to get
55:34
right we do release flags as well um we call them release Flags to um with
55:41
the intention to not use them for a b testing or have them on permanently but
55:47
the the goal is to eventually get everything that is behind a release flag released
55:52
like there is no we have a way to turn them on site wide per customer even per user but there's
55:58
no way to exclude someone and that is potentially we really want to embrace that we want to ship everything but
56:04
think of it as future Flags so we have these release flags and Scopes are
56:09
usually behind the release flag sometimes even behind several so that we can start working on it and
56:15
ship it and will at least like complete the engineering work but we have at that
56:21
point not yet exposed all customers through that behavior and the smell that comes from this is
56:30
that we have quite a lot of unreleased features in our code base now because of
56:37
the circuit breaker like um at the end of a cycle we sometimes um
56:43
determine that this was not meeting our quality bar or the feedback we got another flow of shaper by the way like I
56:50
think feedback comes way too late and then at that point this uh the team has been dismantled
56:55
um so like we learned that this is not um delivering what we anticipated so we
57:01
don't turn it on at the very least not for all of our customers maybe the one customer that is satisfied with it great
57:07
they will run with it but we know at some point we need to get back then it's up to a future betting table whether or
57:13
not we decide to fix it for real or as it happens quite often as you can see
57:19
from the many release flags that didn't um have been like lifted
57:24
they just sit there and maybe um the problem here is that you have a
57:30
lot of unnecessary complexity now in the code you need to maintain all of this
57:35
I believe this is true for software in general anything that is not perfect is
57:41
an ongoing cost and maintenance here it's particularly sad because you
57:47
don't pull value from it the only value is that it's easier for a future project
57:52
to continue working on it but yeah the circuit breaker works for us um by release flex and by having the
57:59
unambitious scope we oftentimes have at least something shipped towards the goals of a pitch
58:06
maybe not the most valuable thing but at least something and then oftentimes
58:11
especially like the last one or two Scopes sometimes we broke in parallel on those um are behind the release flag
58:18
before we wrap up the building say oh there's one last thing I wanted to ask you on the building side and then I have
58:23
about two questions left for you so thank you so much for taking all this time with me on the on the building side
58:30
um you also share notes with me that talked about a replacement for the hill chart that's not actually a replacement
58:37
but like um that's really sad so when we started off
58:42
um the people who have uh read the book and in particular have used Basecamp
58:47
before we're saying oh it doesn't it will not really work for us because we don't have Hill charts and
58:54
I said well I mean the whole charts aren't really not the most critical piece it really helps conveying the idea
59:00
that everything is an uphill battle until you've found a solution for a particular scope and then it's easy if
59:06
you have digested this we don't need a Halo chart but then still the team was pressing so we have at Menthol something
59:13
which we call Mad Men fault awesome day which is a day every cycle where the
59:19
entire company not only engineering works on whatever they like to improve their own skill sets or company or
59:26
anything but they were like their daily work and I took one of those to implement a
59:32
hill chart tool like really fancy it looked nice like drag and drop like there are many tools out there but they
59:38
they don't look so great and also I wanted a tight integration with our issue tracker so and then we had
59:45
basically one ticket representing a project and you saw that image and then
59:50
you click on it and you can like do like all the fancy movement and new Scopes move them around add just like a few
59:56
notes send it and you could embed this to notion with like web embeds and at a
1:00:03
point I thought oh maybe we ship this as a product itself because it's so cool and then we learned that there was not
1:00:10
much value in her charts outside of the team so I initially I shared the hill shots
1:00:16
of the ongoing projects during our All Hands meeting and people without context
1:00:22
don't know what a scope description really means and I spent so much time making sure that the labels of these
1:00:28
dots would not overlap and everything is legible in the end I learned nobody really cared
1:00:34
but the respective Builder projects themselves and at that point
1:00:40
what gives and soon uh sooner than later the team themselves lost interest in
1:00:45
using them um it was more important to use that two-dimensional scope visualization which we don't have
1:00:52
a good name for scope map I guess um so by now we absolutely don't use her
1:00:59
charts anymore and use um this the two-dimensional scope Maps which don't really reflect progress so we thought
1:01:05
about oh each blob there could be you know a pie chart or we could depicted as
1:01:11
um showing the size shows the total effort and then it shrinks and you leave um as an outline the original size and
1:01:18
then you can see how things basically the remainder of the work shrinks turned out that the team has enough
1:01:23
context um to know all of this so there is not really much there maybe as we grow and
1:01:31
um people who do care cannot have the context anymore because it's too many
1:01:37
projects maybe at that point we have to introduce something again but for the time being who charts
1:01:43
have no value for us I think that's a good segue into one
1:01:49
other question I had um about you mentioned this a couple of times you are hiring you're growing
1:01:55
that's right and um I was wondering since Shape Up is kind
1:02:03
of a niche framework and you've even taken the book that somebody could read and put a totally different spin on it
1:02:09
do you pay a kind of special tax now when you're onboarding people or how do you go about onboarding people into your
1:02:16
process versus you know if they join the scrum team they basically know what to expect what the rituals will be and so
1:02:22
on during our hiring process both Engineers as well as product people are generally
1:02:29
excited some of them know Shape Up and those who don't are intrigued by the
1:02:34
promises so it's generally a very positive vibe that goes that comes from it
1:02:40
after onboarding I don't think it is too much of a change
1:02:46
as an engineer as a new hire you lean on your teammates and just there you have
1:02:51
your Tech lead and from that perspective it's not much different than any other methodology you ultimately get exposed
1:02:59
to a new area and the tech lead Shepherds you along and you work off of
1:03:05
tickets so I don't think onboarding is particularly difficult and what we do is we again thanks to the cycle plan we try to
1:03:13
level up or like um expose
1:03:18
previously Builders to becoming a tech lead and a project so we are in the process of doing this expecting that
1:03:25
basically everybody today needs to be the tech lead for this next generation of Engineers that we have to hire this
1:03:31
year and um so this is so you can like a conscious step we are taking
1:03:39
but I don't think this is unique to shape up and I really enjoy that this
1:03:44
book exists and then our playbooks exist and oftentimes there is but the book says and then we say yeah yeah we tried
1:03:51
that and that doesn't work because of XYZ so yeah I don't see a real problem there
1:03:58
um if anything a builder project really is beneficial over classic kanban
1:04:05
responder work because it gives more structure so what we try to do for new
1:04:10
hires engineering new hires is to put them on a buildup project rather
1:04:15
than working off of the responder board um and just to stay on the topic of
1:04:22
hiring for one more second you mentioned in the beginning how that how you reflected upon needing to hire for
1:04:29
Fitness to shape up as a as an idea or it kind of it demands certain
1:04:35
characteristics of somebody yes maybe you want to speak yeah you need um a good amount of pragmatism like you
1:04:43
cannot strive for the what I often are oftentimes called The Gold version like
1:04:48
the if you had infinite amount of um resources that would be it
1:04:54
um I I even don't believe that like if you have an infinite amount of resources that is not a guarantee for a great
1:05:01
outcome I worked at Facebook before and then the other one is you need
1:05:10
for this autonomy to work you need self-driven people with like customer
1:05:15
empathy that like think in in value they add and not so much technical
1:05:21
only maybe that's the same thing like you don't strive for technical Excellence
1:05:27
but for good enough to meet the value and and yeah maybe that is the same
1:05:33
thing pragmatism and all of it and and that is not everybody's um cup of tea and I I totally acknowledge that
1:05:40
um maybe maybe I took your questions wrong maybe there is a text you have to
1:05:45
pay in form of the people you want to hire but thankfully um
1:05:51
um we are very aligned at the company as to which people we want to hire when it comes to product for example
1:05:58
we have a multi-step hiring process as as it is um and we have a take-home project as
1:06:06
part of our hiring Pipeline and that is write a pitch I want every product person including
1:06:13
the product designers um to be able well I mean both both they
1:06:19
product managers and product designers to be capable of shaping a solution they need to be able to come up with
1:06:25
Solutions and they need to be able to put it in words that are digestible within minutes
1:06:31
um like and then we share with them the template our template we link to the original book as Source material and
1:06:38
then we have a scenario that is not memfold actually but something everybody can understand or should understand if
1:06:45
there are product people and then it's their goal to to write a pitch so I hire for this in mind
1:06:52
yeah makes sense and then I guess it's not so much a text though so you were right to kind of turn that down but a
1:06:58
filter that you have yeah yeah before I come to my closing questions is there
1:07:04
anything you feel like uh we've missed um in preparing for this talk do you see anything that you want to get in one
1:07:12
observation is that in the early days after we successfully implemented this success being defined as we went from
1:07:20
Total everything is chaos to we can finally tackle strategical
1:07:26
um projects strategic projects I think that took us about six months
1:07:32
um and after that other teams like the go to market team they wanted to adopt a shape up as well that didn't go so well
1:07:40
um I am not too deep into that to answer why um but I can say that they were like
1:07:46
intrigued by the idea and wanted to adopt it maybe there is something there
1:07:51
um maybe it is just um like coincident that it didn't work for us
1:07:56
um maybe maybe try it out oh yeah we still do retrospectives and I
1:08:01
think that is that we do that during cooldown and that is a great source
1:08:09
um of ideas to refine the process and Define
1:08:15
redefine all of this oftentimes that leads to new experiments we want to try for example
1:08:21
project management should come from engineering or Cadence needs to be altered or we need a real re-brief as a
1:08:30
tool to inform other functions in the company and also write perspectives are they
1:08:36
within the Builder teams or are they across the whole cycle everybody so we do per Builder team one dedicated
1:08:43
retrospective and then the responders all together Drew one platform team does one solution and does one and then we do
1:08:50
a roll up so from the retrospective we condense action items um and these action items are then
1:08:56
shared across all but what we do because in order to keep the iteration kind of
1:09:01
the same then for everybody I guess that's swag exactly so oftentimes like um and then we like we have this culture
1:09:08
at my fault where we give um shout outs and and Kudos um a lot like during all hands we have a dedicated select channel
1:09:14
for it but that also happens during retrospective and oftentimes like there are learnings in the Builder project
1:09:19
that affect platform and responders for example it was so great they could help us and then it's really interesting to
1:09:26
see how platform perceive that at the same time and sometimes that that holistic perspective leads then only to
1:09:32
the change in process great yeah the responsibilities of a
1:09:37
builder are many I forgot to mention but also user facing documentation user here
1:09:42
being another engineer but still is part of the deliverable so coming back to
1:09:47
your tax you're paying yeah if you need a well-rounded experienced crowd to to
1:09:54
run a successful Builder project but I think one way you are making this work if I understood you correctly is by
1:10:01
having these detailed playbooks and to be able to share the expectations very transparently with everybody in the same
1:10:08
way yeah I mean transparency certainly is a quality of our company but in the end it's um the individuals and every
1:10:15
person um on the company who has to meet these expectations and
1:10:21
I I can imagine that this is difficult I mean hiring a general is difficult I have a hard time finding
1:10:28
um the the right people but I hear that this is true everywhere so
1:10:33
and and I can for my past experience yes that is true I don't think if you set
1:10:38
the goal of a hiring experienced uh people with our particular needs I think
1:10:45
it would be equally challenging with or without Shape Up makes sense all right second to last
1:10:52
question what advice you can be quick on this one but kind of
1:10:58
what tidbits of advice would you give other teams thinking about trying shape up and maybe the way to think about it
1:11:04
is if you know what might you tell Haiku who's living in a parallel universe
1:11:09
that's off by one or two years is there any shortcut you could have taken to where you are today or is it really did
1:11:15
you have to go through all this pain of iterating your way here I don't call that pain
1:11:21
and I'm not saying that we are converging to the one truth um the team is changing and so are the
1:11:29
preferences I wouldn't be surprised if in a year from now we are closer to
1:11:34
something we have unsuccessfully tried in the past that is now working so I would totally Embrace iteration not um
1:11:41
to reach you know Enlightenment but to embrace the nature of an ever-changing
1:11:48
environment uh what would I tell myself I think independently from Shape Up
1:11:54
for me this whole product thing was really new and still is uh when I'm interviewing people oftentimes these
1:12:00
people have more experience than the like actual product work than I have and we've counted in years
1:12:07
um embracing that uh when you're when you're only thinking about shape up like maybe all of this sounds new to you like
1:12:14
just like try it out uh it it's easy to say at a
1:12:19
company that is relatively small uh where you take on a lot of risks anyway but I would generally
1:12:26
um advise people to just um try out what they if there's something broken and there's a need to make a change
1:12:32
um I found shape up as a viable Foundation next to
1:12:37
more popular approaches lastly I'm always on the hunt for
1:12:42
interesting book recommendations that go beyond the most recommended product management product development books so
1:12:49
my question to you is what book can you recommend for our audience that has an impact on your work but that's from a
1:12:55
different domain maybe yeah if there's something so let me first start like you asked me that question uh like you sent
1:13:00
me that question last night and like I have some books on the like uh here um and actually the first thing I come
1:13:06
to moment is actually a product um book it's um called Product roadmaps relaunched
1:13:11
um and this is great material if you want to rethink Road mapping
1:13:17
um and don't treat it as a delivery schedule but because it's um on the topic I will leave it out still a brief
1:13:24
recommendation and then the next thing I'm an engineer by heart a book I read probably 15 years ago dreaming in code
1:13:32
this is it was really fun I think for some people especially the first 200 Pages or so are a bit dry a very
1:13:39
technical um Scott Rosenberg describes a real world
1:13:44
um project that arguably Falls in that category of infinite resources infinite time and it didn't go nowhere and maybe
1:13:52
I should read it again again it's been like 15 plus years I think from my perspective today they
1:13:59
were lacking strong product in that journey and I think a strong like
1:14:05
product team would have um pushed like this is a spoiler it didn't really go nowhere this is a open source project by
1:14:11
now and you can totally use it but it's not popular I think proper product work could have made this
1:14:18
a success but then there's one thing I really want to share and it's another book it comes from my hiring work last night I was
1:14:25
reviewing one of these take home um projects and the kinderberg
1:14:31
are closed with a section so like usual pitch and
1:14:37
intertwined with thought process but then the last page was so I ran this
1:14:43
prompt our description of the problem which is not even in the shape picture form but like just the prom the general
1:14:50
thing and then you need to transfer it into the problem statement and like value and all of it Plus Solution I put
1:14:57
that through chat GPT like we all have heard about AI in the recent months and
1:15:02
its advancements so the candidate um also put what AI had produced based
1:15:09
on the prompt and at first I was in disbelief because that was a pitch better than some I have reproduced by
1:15:15
humans so I went over last night which at GPT and actually try that ourselves using our interview pitch prompt
1:15:23
and it's amazing so it doesn't even teach like that's without our template
1:15:29
just the problem prompt and it says product pitch it doesn't even mention Shape Up and the structure is
1:15:37
surprisingly close to um the structure um that's spit out in the end surprisingly close to a pitch
1:15:44
format including solution and problem statement and then for those of you who haven't tried this out you can actually
1:15:49
push a button to re-um render like reiterate and propose different answers
1:15:55
and each time I was reading through that of course like sometimes the format diverged more from shape up than other
1:16:01
times each time I learned something so um that was maybe they literally there was a rabbit hole section uh or a value
1:16:08
section and each time there was something ah interesting that is a really interesting point here so I will
1:16:14
make a change to how I'm going to work on pitches where I will use um chat GPT
1:16:20
to um as an augmentation to my tool set to detect gaps in my pitches
1:16:28
where I have basically yet another person or like um
1:16:33
source to provide ideas towards that pitch to maybe discover blind spots that
1:16:40
I otherwise would have missed so that would be my recommendation that's super interesting I like that the augmentation
1:16:46
was though you're learning it not the oh I don't need to hire anymore oh no I mean like the actual solution was not
1:16:53
like really implementable I mean it was on the surface okay but like it's not
1:16:58
what you really need no I mean it's it's great to discover gaps and who knows maybe in a few years it will actually be
1:17:04
able to do that and then the the focus of your work is to carefully
1:17:09
um craft the prompt um I don't mind but like this was
1:17:17
um a surprise to me last night all right Haiku thank you so so much for your time
1:17:22
um where can people find you online if they want to follow up with questions or connect with you connect with me because
1:17:28
they want to start a career at memphis.com well that would be that um aforementioned website uh it's I think
1:17:35
it's memphis.com careers we are an international company I'm working in uh
1:17:41
like West Coast where we've been found in San Francisco we have an office in Boston but the product team we try to
1:17:46
hire in the EU time zone and Berlin so at menopause you will write me at haiko
1:17:52
at memphis.com and then personal website is highcorebearance.com I'm sure you can link to that from the show notes
1:17:59
there's not much on it a few hobby projects of mine um but then
1:18:05
um certainly ways to reach out to me and please do if you are interested in
1:18:10
working with us cool thank you so much Aiko it was a pleasure thanks David
1:18:15
[Music]
1:18:23
Michael I certainly did if you like this show it really goes a long way if you
1:18:28
leave a favorable review wherever you're listening to this and to find jobs at companies that work with shape up like
1:18:35
manfold remember to check out Shapers dot Builders again that really is the
1:18:41
domain thank you so much for listening and I hope you have a great day [Music]
1:18:47
thank you [Music]