In self-organized structures you never really know when and where things start.

Are you ready for that? Are you sure it motivates you?

If you are working in a product development company most probably you are doing something wrong if start changes and improvements in a technology departments/teams. Little by little i start to understand that.

Leave developers alone, let them do the work they love and focus instead on the flow and other challenges which require attention and might be missed:

  • Understand and communicate the essence of the product
  • Identify business value and stakeholders’ needs and make sure this is delivered regularly
  • Clarify, negotiate and communicate the important priorities and dates
  • Balance the needs
  • Work effectively with development team(s)
  • Identify, track and address things blocking progress
  • Gather and spread information

Developers can help with all these activities, but most probably they don’t love this type of work. That is why they are not managing the product and don’t want to act as Product Owner or Product Manager.

Stumbled upon while was reviewing my notes. Notes were with a funny titles “Hints for myself” (unfortunately can’t remember where i read it, so can’t refer to the source)

  • Manage Your Mood
  • Don’t Check Email in The Morning
  • Before You Try To Do It Faster, Ask Whether It Should Be Done At All
  • Focus Is Nothing More Than Eliminating Distractions
  • Have A Personal System
  • Define Your Goals The Night Before

APIs help to identify value. API discussions are very valuable when you think about organisational structure. Think about your organisation while reading hints below:

  • Decoupled UI, different interfaces are possible while core logic stays the same
  • Can use 3d party software
  • Easier to delegate to non-domain experts
  • Easier to communicate with other teams & hide certain complexity of specific components
  • Less stupid meetings and communication problems
  • Decoupling from others. API is like a street – you set the rules and others can use it
  • Simplify UI -> others can do it
  • It helps to sell the product, as you are focused!
  • You can give away the boring stuff and focus on what’s important
  • You can construct things faster, like a LEGO!
  • You can experiment faster with features
  • You can experiment with business model

APIs give you technical agility and allow to grow and experiment faster – how organize a company, how to build stuff. But it’s not easy…

Here is a couple of questions to ask before you want to build a feature.

If we built <feature name>, what measurable business benefit or other positive outcome would be achieved?

If we built <feature>, which roles or user personas would use it, and how often would they use it?

When being a Product Owner what else do you treat as important before you start building something?

WordPress SEO fine-tune by Meta SEO Pack from Poradnik Webmastera