Want to collaborate?

Right now, you can get in touch with me for a few things:
Live Streaming
Beta testing new products
Brainstorming
+ more
Follow

Ilona Kędracka

On my way to become a kick-ass Product Manager. Interested in all things product, lifelong learning and foreign languages.
Read more
I'm available for
2022
Jun 27, 2022
Observing the pace of work and struggles that me and my team members face in the process from idea to delivery, it seemed that there are several issues that slowed us down and sometimes resulted in waste either on design or engineering side:
  1. Designers and developers worked in parallel, but not together - and this gap is where lot of assumptions made along way by either of the parties were in conflict with one another ("You planned this to be displayed all together in a single page, but the way I designed the API doesn't support this case")
  2. There's not even a point of "diminishing returns", but a point of "decreasing returns" when it comes to number of people involved in an ideation/scoping session (a group made of dev+PM+UX comes up with pretty much the same ideas and conclusions as the group made of 3 devs+PM+UX, but the 1st one is easier to manage and details not covered during the meeting can be ping-ponged asynchronously)
  3. Lack of ownership of particular epics can lead to the case of an "abandoned ship", where if everybody is responsible for finding answers to a certain question, then nobody really cares to find them before the new sprint starts (which is not to blame anyone from the team - it's just how people work, myself included)

Having said that, we're experimenting with a new process which helps to combat all the three points above:
  1. We set up a problem-centered product trio made of a UX designer, a PM and a dev (whenever possible, it should be the same dev which is going to implement the solution for the problem later to shorten the lead time even more)
  2. We start with an idea of a solution (which is the outcome of the brainstorm described here)
  3. We story map the solution assuming it's already in place - we place ourselves into user's shoes, write down their steps and assumptions identified along the way
  4. Story map is enough for the designer to prepare initial mock-ups and for a developer to specify and find answers for outstanding technical questions ("can we reuse API X for this reason?")
  5. We set up a channel for the three of us to quickly feedback on interaction/mock-ups/random questions that pop into our minds
  6. Dev drafts user stories which by the time of the refinement are usually ready for the discussion with the broader team and have enough info to be estimated
So far it's been working wonderful for us - we're usually done with the scope, mocks and corner case coverage in less than 3 days. We only gave it a shot a couple of times, so I'll post an update once we apply this process to 10+ problems, but I'm in high hopes it's going to be a game-changer for our teams.

Stay tuned for updates as there's more to come. So far, I'm adding "story mapping" to my PM toolbox, sitting right next to the "individual brainstorming"
Read more
Jun 07, 2022
We had a really cool brainstorming session with my team this week! 

By following Teresa Torres' guidelines from Continuous Discovery Habits book&blog:
1. Make sure the development team understand the business process well,
2. Give people time for individual ideation,
3. Actively involve the entire product trio,
4. Make sure people have a chance to look at others' ideas,
5. Leverage the "shower thoughts" mechanism

We actually came up with really compelling solutions to user problems. We also separated voting by "I really like this" and by "I think it's pretty easy to implement" to identify the best solutions on the intersections of the two. It was the 2nd brainstorm activity of this kind I led and I'm really happy with the result. 
Read more
Loading...