Areas of concern for digital product management

I believe that the following areas are those that should be the concern of, and areas of action for, digital product management.
Spotting where problems are in software, in code, in tests, in systems, in processes and procedures.
Collaborating with others to propose or identify or create solutions.
Needing to have a mental picture and idea of the whole product environment in order to understand technical possibilities and limitations.
Being able to follow if not run the full release cycle, usually with other's involvement and help, to produce a workable copy of the software and operate it.
There are whole specialisms and domains of knowledge that you need to be aware of if not expert in, for example:

• Creating digital media including but not limited to; graphics, video, audio, fonts, text, formatted text, electronic books, styles, models, and many more.
• Programming in various computer languages. Knowing the distinction between interpretable and executable software, between scripts, byte code and machine code, the necessary extras (libraries) that allow the software to run.
• Wireframes, prototyping, paper prototypes, incremental and iterative development.
• Testing, as a of broad specialism that also includes programming.
• Source code control systems and document versions using github or subversion or cvs or other systems.
• Packaging, installation, and package management.
• Issues of legacy systems; in one way anything becomes a legacy system the moment it gets released. This area can be approached in different ways, data versus execution or running environments.
• Localisation (aka l10n) and Internationalisation (i18n) are really important areas, unless of course you want to ignore international customers/users. Localisation is highly specialised but increasingly easier to address through the enhanced support offered by software development environments. So no more need to 'hard code' translations or language rules, these are now provided for by standard development libraries. So to, it is now a commonplace for computer fonts and character sets to support extended and unicode character sets allowing the display and use of text in any language, type, and linguistic framework. For example, left to right, right to left, top bottom, sentence patterns used in european, middle east and asian languages.
• Online help systems including pop-up and context sensitive help, often the first and only documentation provided with software.
• The components of and services provided by operating systems.
• Managing vendors and other third party contributions.
• Data visualisation.
• Help desk and frontline support systems.
• Sales and customer relationship management.
• Quality management systems; not usually an area that software development prides itself on but essential and necessary nonetheless.
• General technological infrastructure like internet protocol, ip addresses, networks, network protocols, subnets, routers, switches, wired and wireless, firewalls, packets, packet sniffing, shared drives, cloud storage, routers, domain control, ftp, port management, virtual machines, password managers.
• Web hosting, website builders, domain registration and management, email server setup and settings, canonical name record (CNAME) and the Domain Name System (DNS) and IP addresses.
• Content management systems, workflow and web services (things like Wikis, Wordpress, Joomla, Drupal and many others).
• Databases, ranging over flat file, to relational, sql, object databases and post-relational databases.
• Web services, evolving capabilities of HTML, REST, and other important API services.
• LAMP architecture (i.e. Linux, Apache, MySQL and PHP) 
• MEAN architecture (i.e. MongoDB, Express, AngularJS, Node.js)

No to No UI, more responses

The idea that UI is the problem has exercised minds for a long time. It is an assumed aspect of Don Norman's Design of Everyday Things. But presenting it in terms of a dichotomy of more or less really does miss the point. Timo Arnall responds to the urge to 'invisible' design; effectively to strive to make the design disappear from the user's awareness. (link)

Think instead perhaps of presenting more information for use rather than attempting to hide everything away. People are going to come up with their own theories anyway, all you achieve by hiding stuff is making people ignorant. Not everyone wants or needs the world to work like a magic trick.

What does a product manager do? What is value?

An hour of reflection by Jez Humble

Value is what gives your life meaning... The trouble with estimates is that they're wrong. Especially as predictions they're terrible as they set up the wrong expectations. 

Estimation is not just valueless, it actually has negative value because people have the wrong expectations. People expect your estimates to be right! And the one thing I can tell you about your estimates is that they will be wrong! And that sets up bad expectations.

What estimation does do, is estimation helps create a shared vision of what you're going to build!

The Critical 10 in any 'pitch'

From the Official SlideShare blog How to Be ‘Pitch Perfect': 5 Essential Elements for Your Pitch Deck

<quote>
Include the Critical 10
A solid pitch deck always touches on 10 items:
1. The Company/The Vision
2. The Problem
3. The Solution
4. The Opportunity
5. Product/Service
6. Team
7. Revenue Model
8. Competition
9. Financials
10. The Ask
</quote> 

After discussing Soul of a New Machine: Wordle-like keywords

General aspects of high-tech production

There is no 'law of physics' or mathematics that governs the higher level design of systems, of software, of devices. Agree a definition of what high-tech production is in general.
Designing and building something to solve a problem.
Is software development a kind of engineering?

No Yes Artistic Expressive

What words describe high-tech design work, its outputs, its ethos?

Craft Purpose constraints requirements

design plan optimisation

craft first-time (all the time) creative

What roles are essential?

architect designer user

Engineering culture and work practices

What impressions do you have of the sense of a high-tech workplace?

Respect Dinosaur value Pigeonholed Geeks

What reflects the values of design work?

Autonomy Responsibility Problem-solving Empowering

challenging 

management hierarchy technical strength 

List engineering management practices you identified at Data General...
Using that list, contrast it with process and practice specifications of different life cycles, management frameworks and methods. For example, what aspects of the culture in Data General's Eagle could be depicted as good management practice? If you had to give them a label would any of the practices at Data General fit into the practices of Extreme Programming?

Innovation, management and leadership

Who drove the Eagle? Who designed it? What did they need to do to express it?

 Ed de Castro? Steve Wallach Rosemarie Tom?

What strategies did they bring into play?

Machiavellian political power new

creative context conditions LIMITS timing
WORK do/act process

What roles were essential?

Faclilitator  buffer Leader

designer followers lieutenants

Teams and interaction.

What happens in teams? What works well, what doesn't?

Stability 3mths 3 years deadlines
realism Ownership specialisation pushing

creative games limits Socials
social club reviews dog racing

 Utlimate Test Frisbee

Trust

---

Additional resources: (thanks to Alex)

Main page for the CS330 course

Picture of the team, Kidder & Tom also a map of the Adventure game and some block diagrams

Links to advertisements and printed company material, pictures of the machine & boards and loads of technical documentation. Also links to publications & patents (as mentioned in the book) on the topic.

Picture of the team together with names & quick bio

Bio on Ed de Castro

Seminar at the Bank of Ireland Innovation Lounge

Special off-site lecture on Thursday (June 4) held at the Bank of Ireland Innovation Lounge - Bank of Ireland, 1 Grand Canal Square, Docklands, Dublin 2.

Construction Exercise 2014-15

Some photos from the construction exercise 2014-15 held on 5/June/2015 in Q201, Lochlann Quinn Building, Belfield.

Exercise: Requirements Design Trade-off

This exercise has been adapted from Alexander’s ‘Notes on the Synthesis of Form’ (Alexander, 1964); the simple design problem from section 1 ‘the need for rationality.’ Alexander’s classic design tetrad characterises trade-offs between the major product requirements: simplicity, performance, features, economy.

Objective
Organise, model and explore the interrelationship between different requirements.
Requirements/Design Preparation
1. In groups of 2 or 3 categorise the following non-functional requirements for an imaginary high tech product.
Statement of non-functional requirements

1. A simpler product (system, service, device) will be easier to manufacture and operate.
2. A simple product with fewer features is going to be less costly to maintain.
3. A simple product is easier to construct as it has fewer features.
4. Greater system performance or power is achieved by including more (advanced) features.
5. A highly optimised product is difficult to improve, change, fix or maintain without degrading its performance.
6. A simpler product does not deliver as many features or options as a more complex product.
7. A simple product using fewer specialised parts will not perform to as high a level as one using specialised optimised parts and sub-systems.
8. Adding more features makes the product more difficult to maintain.

2. Consider following product requirements categories: Simplicity, Performance, Feature Set, Build/Operate Economy.

3a. Map these non-functional product requirements to the following categories: Simplicity, Performance, Features,  Economy (+ or - for complement or conflict). 

3b. (Online version) Use a Jamboard to draw the trade-off diagram (link). Each group draw numbered arrows with plus or minus indicators (+/-) to complete the diagram, illustrating the relationships between the requirements listed. 

Discussion:

• Do requirements influence design decisions?
• Is a unique solution possible satisfying all requirements?
• Do requirements specify design?
• Is it possible to overcome contradictory requirements?
• Would more detail enable us to overcome contradiction?
• Will computer modelling of requirements enable conflicts to be resolved?
• Does the design of the product limit which requirements can be delivered?
• Is there always a trade-off between requirements and design?

Reference:
Alexander, C. (1964) Notes on the Synthesis of Form, Cambridge, Massachusetts, Harvard University Press.

---

A Collage of Outputs from the Requirements Exercise

Exercise: Follow up on construction learning points

Relate the actions in the construction exercise to concepts of:

• Quality/Cost/Time/Scope.
• Reqs-Analysis/Eval-Sourcing/Development-Test-Implement/Use-Maintain.

Ask yourself:

• How did your group organise the construction work?
• Is there a 'best' way to organise the construction activity?
• How many people can work on the job at once?
• At what point does adding more people make the job slower?
• What happens when you change the shift (give the job to new workers)?
• What is the design?
• Who did the design?
• Where was/is the design work done?
• Would the exercise be improved if the instructions were in colour?
• What did you do when you couldn't find a piece?
• Did your group experience any setbacks?
• When an error occurred what was the root cause of the problem?
• Task completion time ranged from 20 to 40 mins (some groups do not complete).
• How can we account for the large variation in group performance?
• Would your performance improve if you built it again?
• Would you performance improve if you built it a third time, a fourth time?
• What if you discovered the grey pieces were faulty after making 100 units?

Take the following short survey to reflect on your understanding of this exercise
(Click here n.b. SurveyMonkey registration may be required)

Nice quotes:

"The pieces are the design, there is a lot of the design tied up in the actual pieces, you can do some things, you can't do others." 

"The elements and sub-parts are 'designed' too, the design goes from the low level right up through to the high level" 

"We had to improvise, you know, to understand a diagram you have to play around with it, see it from different angles, to really make sense of it." 

"The design is our process, our involvement in translating from one thing, the printed instructions, to the other, the thing we built."

Seminar: "Build the Thing Right"

Our next seminar, on Thursday 4th of June from 2pm to 6pm, will be hosted in the Innovation Lounge - Bank of Ireland, 1 Grand Canal Square, Docklands, Dublin 2.

Introduction

Digital design and development is the innovation engine of the ICT-enable organisation. However collaborative production and delivery of robust systems presents significant challenges and team issues. This module provides an understanding of approaches used by professionals in this vital function, from the perspective of managers who supervise developers or liaise with them during innovation projects.

Scope

The seminar's theme is "Build the thing right".

The focus for this session is on techniques and processes used for managing design and development to deliver value. We cover current issues of the management of software production ranging from traditional sequential engineering approaches through to agile and lean methods. We consider how lifecycles and methodologies are employed to balance the tension between requirements for orderly production and the need to respond to change.
We will review key perspectives on the systems development lifecycle including:

a). Requirements,
b). Implementation,
c). Maintenance,
d). Evaluation.

Practical exercises will illustrate the dynamics of design and coordination activity on teams. The goal is to highlight prevailing assumptions around the design process and contrast these against empirical evidence generated from the exercise. Implications for planning and management are discussed.

Exercise: Guindon Design Activities
Exercise: Planning Battleship

People, Empathy and Design

Putting Anthropology to Work: People, Empathy and Design. SILS Seminar — MIS Subject Area Web http://ow.ly/Nlgtl

Thoughts on recording classroom sessions...

UCD does not currently have a policy on lecture recordings made by students from the general population.

In view of this I adopt the following policy for my own classes.
In general I do not record or permit recording of my classes for the following reasons.
Classroom discussions may involve confidential disclosure, personal opinions, and draw on privileged information, from students, guests and lecturers. Furthermore the learning process may itself be compromised if being recorded i.e. students may be reluctant to offer opinions.
In certain instances I will permit recording and release edited output, for example to produce additional learning materials or as a statement of record.

First some principles:

Ask permission first. Permission may be withheld.

No copyright is conferred therefore no copies should be made nor should they be distributed to others. Likewise no backup copy to be made.

The recording should be destroyed after a reasonable time, i.e. after reviewing and making notes, less than 3 months.

Turn off the recorder when requested.

Paraphrasing the University of Warwick policy: I believe that attendance in class is an important formative experience and that note taking during class is an important skill that must be practiced to be learnt. Therefore as a general point, recordings are not made to overcome class absence. Absentee students (whether due to illness, work, or other incapacity) have access to the slides and extensive notes provided on the website. 

Unless otherwise permitted by prior consent:

1. Permission is sought by whomever is recording part of a class.

2. Recordings are to be deleted after use.
3. No copyright is given.

4. No distribution allowed.

From time to time, if I (the lecturer) determine a need to record, photograph or video part of a class or exercise I will notify and seek the permission of those involved.

http://www2.warwick.ac.uk/services/aro/dar/quality/recordinglectures/
http://www2.le.ac.uk/offices/sas2/quality/recordinglectures

This statement does not negate UCD's guidelines for students with special access requirements (link).

Readings: The ISO and SDLC in the workplace

Fishman, C. (1996) They Write the Right Stuff. Fast Company.

Wareham, E. M. (1994) ISO 9000 and the very small firm. IEE Review, 40, 207-09.

---

Read the articles and provide a thoughtful observation or question (post to your blog).

Exercise: Follow-up on the NATO Conferences on Software Engineering

Reflection on the key issues discussed in Naur & Randell "NATO Conference on Software Engineering," 1968 (link) and Randell & Buxton "Software Engineering Techniques; NATO Conference Proceedings," 1969 (link).

In no particular order...

• Operational problems
• Control
• Project failure
• Changing requirements
• Scope management
• Documentation
• Reacting to change
• Costs
• User involvement/input
• Software limitations
• Time to delivery
• Design standards
• Testing
• Design as art
• Scale of project
• Knowledge is a scarce resource
• Production problems
• Resistance to change
• Brittle nature of software
• Hardware limitations
• Interoperability of systems
• Ripple effect in society/market/users
• Management methods
• Communication
• Clear requirements
• Design process
• Coordination
• Team stability

---

Click here to take a survey on the key issues

Exercise: Crowdsourcing research methods

Objectives (5') - S1-S2 

To quickly identify examples of interpretive research methods
To conduct independent research
To experience and reflect on group work
Note: This exercise helps you prepare for the research project which must employ at least two different research methods to conduct the empirical study (see ID Look, ID Learn, ID Ask, ID Try).

Transition (5')

Identify groups

1x IDEO cards to each student

Independent research starts (10') - S3 

In groups of 2 or 3

• Critically evaluate one of the research methods provided.
• Identify an actual example or extrapolate and suggest how the method could be used (without visual props). 
• 10' to read, research and prepare of which 5' quiet time.

Presentation delivery (40')

20x 2-minute presentations (introducing each member and systems experience) and field one quick Q&A on the subject matter.

What future, a technical career path?

The link between professional practice and career path progression represents one of the seemingly intractable problems faced by firms in computing but also science industry, high-tech, design, and engineering is the issue of practitioner career paths in contrast to management career paths. How far can a gifted architect, designer, engineer progress before the organisation fails to offer further challenges, opportunities, responsibilities etc. How far can an engineer be promoted before reaching the 'glass ceiling' beyond which it seems that only those with marketing, accounting or finance backgrounds progress to the executive, the 'c-suite', or the board room?

Certainly there are exemplars of programmers, engineers, technicians, architects, designers achieving great corporate and personal success.
But for each of these there are many who love doing what they're good at but felt they had to move into management in order to progress their careers.
And there are many more who stay in product development, design and engineering and languish to an extent because the pay is not kept in line with the equivalent on a management track.

Is there a technical career plateau? If so then why and what can we do to address it?

What about approaching this from the perspective of 'the profession' and link excellence in work practices (i.e. those practices articulated in XP in all its gritty glory) with career path, progression and professionalism.
A professional practice-oriented perspective should be devoid of proprietarianism (via the trademarked & proprietary methods business).
It would necessarily need our active involvement through our various professional societies, ACM, IEEE, IEE, IEI, IFIP, etc...

Further reading...A short piece by Alicia Clegg in the FT "Companies face up to the technical brain drain challenge"

Requirements are the devil.

Questions that keep coming up from business people managing development projects:

"shouldn't I build a blueprint a software company could use to directly build the plattform?""Isn't focusing solely on User Stories letting the software company a little bit too much freedom regarding design?"
"I think I need to describe the processes between differrent modules, how do I do this with just User cases?"
"Where can I define the database structure and security issues?"

In response, to be clear; of course you can design your interface, you can even design your database schema, both of those activities are useful and provide a basis for starting the project. BUT neither are sufficient to bring the project to market nor are they likely to be retained if you actually produce the project.

Why? Because you hire specialists to do design for you. The thing you bring is your judgement, appreciation for use and usability, the specialised domain knowledge you possess, your commitment to the project, your access to financial resources or gateway into a market etc.

In my opinion you shouldn't even be thinking in terms of modules, database structure or security solutions. Although you should be conscious of the need for all of them to be present or resolved.

Unless of course you are the developer.


As a product manager or project leader for development, at some stage you are going to have to capture basic requirements (look back to this post).

But be careful you don't stray into specifying the system design!
Relax, the people you hire to do the development should have the freedom to offer the best design they can. Note that User Experience design is a separate specialisation from application architecture design. You should actually bring in different specialist skills for these two very distinct disciplines.

The current practice for a system requirement is that it be:
* uniquely identifiable
* that it identifies the customer who requires it and why
* that it is expressed in goal driven terms rather than by specifying the implementation
* e.g. that you express it as a 'use case' using the storycard syntax "as a.. I want to.. so that.."

The same goes for functional and non-functional requirements. The main difference is in how testable they are.

Nearly everything else you produce for project planning and development is a design artifact not a requirement.

Reflect on this provocative opinion piece by Michael Schrage

"...have the wit and courage to ban requirements from every systems, process and innovation proposal made to top management. (Instead) Put use cases front and center in your value creation efforts."

blogs.hbr.org 12:31 PM Tuesday September 6, 2011

Also see this post on an underlying theory for requirements.