A couple of weeks ago, I was approached on LinkedIn if I wanted to give a talk at ProductTank Vienna. As I’m passionate about everything Product and wanting to do more public speaking anyways, this was a nice surprise and I accepted. 😊
When it came to which topic I actually would talk about, one thing came up my mind pretty quickly – I think there are not many topics which are as essential to the overall culture, motivation, buy-in and lastly, success of your company as having a purpose that people stand behind and a compelling mission that drives them, both based on a user-centric mindset. So this Thursday, I was having my talk at ProductTank titled “The importance of a compelling mission and a user-focussed strategy”.
As the session was recorded, you can watch it on YouTube in case you’re interested.
There’s a couple of things I learned from the talk yesterday:
I need to check my sense for timing. The talk was scheduled for about 20 mins and I took somewhat around 27-28 mins, so I’ll do test runs and watch this more closely in the future.
Generally being someone who doesn’t like sitting still, yesterday I realised I really like to walk around a lot also while presenting. This works perfectly fine on a stage, but can be tricky in a more “cramped” home-office setup, which led to me walking out of frame a couple of times. 😁
Also, as much as I love interacting with people in real life, I realised that in a remote setup I sometimes find it a bit awkward to maintain “eye-contact”, i.e. looking directly into the webcam, which could lead to people feeling I’m not addressing them directly.
Besides those topics, I’m really happy with how the talk went and I’m very much looking forward to repeating this on further occasions!
Attending a Google Analytics and Google Tag Manager training today – offered by Google itself and best of all, free! I can only recommend it, here is an overview of all currently available Google trainings (e.g. Analytics, AdWords, Tag Manager, UX for Mobile, etc.) in Austria: Google Trainings in Austria
Some mobile apps have a poor user experience, some have a really great one. Time for positive feedback: I think car2go has a pretty awesome mobile app! I signed up for an account about two years ago but until now, did not use the service as a) I own a car and b) public transport in Vienna works absolutely fine and is cheap. However, visiting Burda Hackday 2016 in Munich this weekend, I had bad weather and was in a hurry, which is why I tried car2go. My conclusion: Getting the cars displayed in the app, reserving a car, giving feedback about the condition, ending the ride, etc. – everything worked fine and was absolutely intuitive. Great job! :)
The definition of ready and definition of done can potentially be a matter of discussion between product owners, developers, quality engineers, designers and stakeholders – to have a guideline, I think the following suggestions can be quite helpful for this topic:
Definition of ready
Description of GUI with mockups & designs added
Description of story is consistent and clear
Acceptance criteria completed
Dependencies with third-party applications clarified (e.g. CRM or finance systems, DWH, etc.)
#1: All users are customers
#2: Your customer took the time
#3: Your customer is abrasive and demanding
#4: Your customer doesn’t understand your product
#5: Your customer doesn’t care about your workflows
After over eight years of software product management in different industries (web portals, banking, payment, etc.), I worked with different software development methodologies – from waterfall approaches to agile models such as Scrum or Kanban. In my opinion, every approach has its right to exist and might be the best possible solution in a given situation, depending on the type of project, culture, requirements, degree of maturity of all involved people, etc. I really love working with Scrum or Kanban and recently wanted to come up with a summary of all differences between these two methodologies, since lines seem a bit blurred here in my opinion. Here’s what I come up with:
Artifacts: Scrum board, backlog, different types of requirement hierarchies (e.g. theme, epic, story, task), burn-down chart, velocity, etc. in Scrum vs. only a board in Kanban.
Iterations: Yes (sprints) for Scrum vs. no (a continuous flow) for Kanban.
Estimations: Yes for Scrum vs. no (items of similar sizes) for Kanban.
Changes: To be defined, groomed and estimated for the next sprint in Scrum vs. added to the board as needed in Kanban.
Roles: Product Owner, Scrum Master and Team in Scrum vs. Team and other needed roles in Kanban.
Teams: Cross-functional in Scrum against teams which can be specialized in Kanban.
Ceremonies: Sprint planning, daily stand-up, sprint review and sprint retrospective in Scrum vs. daily stand-up, regular reviews and retrospectives on set dates and continuous planning in Kanban.